6.4 Мова SQL як стандартна мова баз даних
Визначення реляційної системи вимагає, щоб весь діалог з базою даних вівся на одній мові - іноді його називають загальним підмовою даних (comdivhensive data sublanguage). У світі комерційних систем управління базами даних такої мова отримала назву SQL.
Мова SQL став стандартом мов запитів для роботи з реляційними базами, для архітектури файл-сервер, клієнт-сервер, а також в умовах застосування системи управління розподіленими базами даних, досить потужна мова для взаємодії з СУБД, яка обробляє запит, знаходить необхідні дані і посилає їх користувачеві.
SQL використовується для маніпуляцій з даними (data manipulation) вибірки і модифікації, визначення даних (data definition) і адміністрування даних (data administration).
SQL є інструментом, призначеним для обробки і читання даних, що містяться в комп'ютерній базі даних. SQL - це скорочена назва структурованого мови запитів (Structured Query Language). Як випливає з назви, SQL є мовою програмування, який застосовується для організації взаємодії користувача з базою даних. Насправді SQL працює тільки з базами даних реляційного типу.
У обчислювальній системі є база даних, в якій зберігається важлива інформація. Комп'ютерна програма, яка керує базою даних, називається системою управління базою даних (СКБД). Якщо користувачеві необхідно прочитати дані з бази даних, він запитує їх у СУБД за допомогою SQL. СУБД обробляє запит, знаходить необхідні дані і посилає їх користувачеві. Процес запрашіванія даних і отримання результату називається запитом до бази даних. [10]

6.4.1 Функціональні можливості мови SQL
Сьогодні SQL представляє собою щось набагато більше, ніж простий інструмент створення запитів, хоча саме для цього він і був спочатку призначений. Незважаючи на те, що читання даних як і раніше залишається однією з найбільш важливих функцій SQL, зараз ця мова використовується для реалізації всіх функціональних можливостей, які СУБД надає користувачеві, а саме:
Організація даних. SQL дає користувачеві можливість змінювати структуру представлення даних, а також встановлювати відносини між елементами бази даних.
Читання даних. SQL дає користувачу або додатку можливість читати з бази даних, що містяться в ній дані, і користуватися ними.
Обробка даних. SQL дає користувачу або додатку можливість змінювати базу даних, тобто додавати в неї нові дані, а також видаляти або відновлювати вже наявні в ній дані.
Управління доступом. За допомогою SQL можна обмежити можливості користувача по читанню і зміні даних і захистити їх від несанкціонованого доступу.
Спільне використання даних. SQL координує спільне використання даних користувачами, що працюють паралельно.
Цілісність даних. SQL дозволяє забезпечити цілісність бази даних, захищаючи її від руйнування через неузгоджені змін або відмови системи. [10]
Таким чином, SQL є достатньо потужним мовою для взаємодії з СУБД.

6.4.2 Переваги SQL

SQL - це легкий для розуміння мову і в той же час універсальне програмний засіб управління даними. Успіх мови SQL принесли наступні його особливості:
• незалежність від конкретних СУБД;
• переносимість з однієї обчислювальної системи на іншу;
• наявність стандартів;
• підтримка з боку компанії Microsoft (протокол ODBC);
• реляційна основа;
• Високорівнева структура;
• можливість виконання спеціальних інтерактивних запитів;
• забезпечення програмного доступу до баз даних;
• можливість різного представлення даних;
• повноцінність як мови, призначеного для роботи з базами даних;
• можливість динамічного визначення даних;
• підтримка архітектури клієнт / сервер. [10]
Всі перераховані вище фактори призвели до того, що SQL став стандартним інструментом для управління даними на персональних комп'ютерах, міні-комп'ютерах і великих ЕОМ.
SQL - це промисловий стандарт набору команд для управління базою даних, який використовується середовищем розробки додатків Delphi.

6.5 Середовище Delphi як засіб для розробки СУБД

При розробці системи обліку комп'ютерного обладнання на підприємстві головними критеріями вибору програмних засобів розробки були:
швидкість розробки додатків;
можливість швидкого внесення змін до програми;
можливість редагування та перегляду БД, використовуючи засоби розробки.
Серед великої різноманітності продуктів для розробки додатків Delphi займає одне з провідних місць. За допомогою Delphi написано колосальну кількість додатків, десятки фірм і тисячі програмістів розробляють для Delphi додаткові компоненти.
В основі такої загальновизнаної популярності лежить той факт, що Delphi, як ніяка інша система програмування, задовольняє викладеним вище критеріям. Дійсно, застосування за допомогою Delphi розробляються швидко, причому взаємодія розробника з інтерактивним середовищем Delphi залишає відчуття комфорту. Delphi-додатки ефективні, якщо розробник дотримується певні правила. Ці додатки надійні і при експлуатації мають передбачуваним поведінкою.
Пакет Delphi - продовження лінії компіляторів мови Pascal корпорації Borland. Pascal як мова дуже простий, а суворий контроль типів даних сприяє ранньому виявленню помилок і дозволяє швидко створювати надійні та ефективні програми.
Мова, на якому належить працювати користувачеві Delphi, відрізняється від Pascal не тільки наявністю безлічі нових понять і конструкцій, а й ідейно: у ньому замість мінімізації числа понять і використання найпростіших конструкцій, перевага віддається зручності роботи професійного користувача. Мова Turbo Pascal істотно перевершує Basic за рахунок повноцінного об'єктного орієнтованого підходу (ООП). [2]
У порівнянні з традиційними способами програмування ООП володіє поруч переваг. Головне з них полягає в тому, що ця концепція найбільшою мірою відповідає внутрішній логіці функціонування операційної системи (ОС) Windows. Програма, що складається з окремих об'єктів, відмінно пристосована до реагування на події, що відбуваються в ОС. До інших переваг ООП можна віднести велику надійність коду і можливість повторного використання відпрацьованих об'єктів.

6.5.1 Високопродуктивний компілятор в машинний код
Компілятори мови Pascal компанії Borland ніколи не змушували користувача подовгу чекати результатів компіляції. Виробники стверджують, що на сьогодні даний компілятор - найшвидший у світі. Компілятор, вбудований в Delphi дозволяє обробляти 120 тис. рядків вихідного тексту в хвилину на машині 486/33 або 350 тис. - при використанні процесора Pentium/90. Він пропонує легкість розробки і швидкий час перевірки готового програмного блоку, характерного для мов четвертого покоління (4GL) і в той же час забезпечує якість коду, характерного для компілятора 3GL.
У сенсі проектування Delphi мало відрізняється від проектування в интерпретирующей середовищі, проте після виконання компіляції ми отримуємо код, який виконується в 10-20 разів швидше, ніж код за допомогою інтерпретатора. У Delphi компіляція проводиться безпосередньо у рідній машинний код. Це не може не позначитися на фактичному швидкодії готового додатку.
По всій імовірності, така висока швидкість пояснюється в першу чергу відмовою від демонстрації в процесі роботи числа скомпільованих рядків. Слід відзначити також, що завдяки опції оптимізації сегментів вдається істотно скоротити розмір виконуваного файлу. Можна запустити компілятор в режимі перевірки синтаксису. При цьому найбільш тривала операція компонування і виготовлення виконуваного файлу виконуватися не буде. Середовище Delphi включає в себе такі технічні засоби - інтегрований відладчик, пакетний компілятор і утиліти WinSight і WinSpector. Основне призначення утиліти WinSight - спостереження за системою передачі повідомлень Windows. Утиліта WinSpector - дозволяє дізнатися причини помилкового завершення того чи іншого додатка. [2]

6.5.2 Бібліотека візуальних компонент
Delphi служить засобом для швидкого створення широкого класу Windows-додатків. Delphi враховує багато новітні досягнення в програмуванні та практиці створення додатків і призначений для візуального програмування, коли розробник бачить велику частину результатів безпосередньо на екрані монітора вже в процесі роботи, пов'язаної зі створенням програми. Візуальне програмування дозволяє швидше створити інтерфейс програми, зробити його більш якісним за рахунок найкращого розташування інформації на екрані монітора, уникнути багатьох помилок ще на етапі проектування.
Всі класи бібліотеки візуальних компонентів походять від групи базових класів, які лежать в основі ієрархії Visual Component Library (VCL). Тому ієрархія базових класів VCL продумана надзвичайно ретельно - адже на їх основі створено всі безліч компонентів, що використовуються в Delphi. Особливе місце серед базових класів, крім TObject, займають TComponent (від нього походять всі компоненти) і TControl (від нього походять всі елементи управління). У цілому ієрархія базових класів забезпечує повноцінну роботу розробників у Delphi, дозволяючи проектувати будь-які типи додатків.
Слідом за класом TComponent в ієрархії базових класів розташовується група з трьох класів, які забезпечують створення різних візуальних компонентів. Візуальні компоненти - це різноманітні стандартні для Windows і спеціальні (створені розробниками Inprise) елементи управління.
Візуальні компоненти повинні вміти відобразити себе на екрані монітора і реагувати на цілий ряд нових подій (реакція на мишу і клавіатуру, рух курсору і т. д.). Для цього в них вбудований спеціальний механізм, що забезпечує взаємодію компонентів з графічною підсистемою ОС (GUI).
Вперше у складі Палітри компонентів Delphi 7 з'явилися спеціалізовані компоненти, що дозволяють налаштувати колірну палітру всіх можливих деталей користувальницького інтерфейсу одночасно. Всі вони представляють собою контейнер, що містить кольору для розмальовки різних деталей елементів управління. Розробнику необхідно лише налаштувати цю колірну палітру і в міру необхідності підключати до призначеного для користувача інтерфейсу додатка.

6.5.3 Технології доступу до даних

Будь-який додаток баз даних має у своєму складі або використовує сторонній механізм доступу до даних, який бере на себе переважну більшість стандартних низькорівневих операцій роботи з базами даних. Наприклад, будь-яке таке застосування при відкритті таблиці БД має виконати приблизно однаковий набір операцій:
пошук місця розташування бази даних;
пошук таблиці, її відкриття і читання службової інформації;
читання даних у відповідності з форматом зберігання даних і т. д.
Одним з традиційних способів взаємодії додатку, створеного в середовищі розробки Delphi, і бази даних є використання процесора баз даних Borland Database Engine 5. Він являє собою набір динамічних бібліотек, функції яких дозволяють не тільки звертатися до даних, а й ефективно управляти ними на стороні додатку.
Для роботи з джерелами даних при посередництві BDE в Delphi є спеціальний набір компонентів, розташованих на сторінці BDE Палітри компонентів.
BDE взаємодіє з базами даних за допомогою драйверів (наприклад, ODBC). Для особливо поширених локальних СУБД розроблений набір стандартних драйверів. Робота з найбільш поширеними серверами БД здійснюється за допомогою драйверів системи SQL Links.
Однак BDE не претендує на всеосяжну універсальність і має деякі недоліки. Це, наприклад, зниження швидкості роботи програми, недоліки реалізації деяких драйверів і т. д.
Поряд з традиційними інструментами доступу до даних Borland Database Engine і ODBC в додатках Delphi можна застосовувати технологію Microsoft ActiveX Data Objects (ADO) - точніше Microsoft Data Access Components (MDAC), яка заснована на можливостях СОМ, а саме інтерфейсів OLE DB, який перевершує ODBC за швидкістю.
Даними для ADO можуть бути як звичні таблиці Access або серверні бази MS SQL або Oracle, а також Microsoft Active Directory Service, XML-файли і т.п.
Технологія ADO завоювала популярність у розробників, завдяки універсальності - базовий набір інтерфейсів OLE DB є в кожній сучасній операційній системі Microsoft.
У Палітрі компонентів Delphi є сторінка ADO, що містить набір компонентів, що дозволяють створювати повноцінні додатки БД, які звертаються до даних через ADO. [2]

6.5.4 Елементи управління Windows XP

У Delphi 7.0 вперше з'явилася можливість налаштовувати користувальницький інтерфейс додатків для використання в Windows XP. Це доповнення покликане забезпечити коректне взаємодія елементів управління програми з системної бібліотекою ComCtl32.dll версії 6, використовуваної в Windows XP. Власне всі особливості роботи додатків під управлінням Windows XP викликані саме появою нової версії цієї бібліотеки. Візуальні стилі, інтегровані в Windows ХР, керують зовнішнім виглядом та поведінкою елементів управління. При цьому візуальний стиль використовує настройки параметрів користувальницького інтерфейсу, задані поточної темою. Для управління темами візуального стилю операційна система використовує менеджер тем.
Візуальний стиль дозволяє настроювати зовнішній вигляд елементів управління в цілому і його складових частин. Правила та методи відтворення зберігаються у файлі з розширенням. Mst, який входить до складу візуального стилю.

6.5.5 Генератор звітів Rave Reports 5.0

Delphi 7 - не тільки багатофункціональне середовище для розробки форм, але й дуже зручне середовище для підготовки звітної документації, що дозволяє вирішити деякі поставлені завдання в даній дипломній роботі.
На перший погляд здається, що у сфері створення та друку звітів в Delphi 7 відбулася невелика революція. Замість старого генератора звітів до складу Delphi 7 включений продукт Rave Reports 5.0 від фірми Nevrona. У Rave Reports є і глобальний клас звіту, і класи смуг, і компоненти перетворення даних. Суттєвим нововведенням можна вважати тільки візуальне середовище створення звітів, що безсумнівно полегшить життя творців звітів і зробить їх роботу ефективніше і приємніше. Тим не менш, в Delphi 7 генератор звітів Rave Reports є основним засобом створення звітів та його компоненти встановлюються в Палітрі компонентів за замовчуванням на сторінці Rave.
Ядро генератора звітів забезпечує попередній перегляд або друк звіту. Візуальна середовище створення звітів дозволяє розробляти самі різноманітні звіти, в тому числі використовують набори даних з джерел різних типів.
Набір компонентів надає розробнику інструментарій для управління звітом у додатку.

Глава 7. Обгрунтування реалізованим системи за результатами аналізу гранично допустимої довжини слова за допомогою системи MathCad 2001i

7.1 Постановка завдання

Зосереджена однопроцесорна БД з параметрами: кор.оп. / сек; біт; сек / запр; біт / запр; біт / такт.обм.; , Використовує при функціонуванні технологію інтерактивного ЧМВ з необхідним циклом сек / цикл, причому максимальна складність виконання запиту оператора з реакцією сек / цикл виникає за умов: запр / цикл; інстр / цикл при біт / інстр. Обгрунтувати реалізація застосовуваної в інформаційно-довідкової АСОІУ технології інформаційного обміну за результатами аналізу параметра lсл_доп - гранично допустимої довжини слова - при виконанні кожного із запитів до ОП.
7.2. Розрахункові співвідношення
1. Визначення значення усередненої частині обсягу кешу модуля ЦП, відведеної під запис програм у циклі обробки:


2. Визначення значення частині обсягу СОЗУ, що заповнюється / спустошуються даними:





3. Визначення значення часу реакції БД на запит чол / оп:





4. Визначення значення ефективної інтенсивності процесу супутнього інформ. обміну:


5. Визначення значень загального часу виконання запиту інформаційного слова у ВП, максимальної інтенсивності, тривалості етапу розгону процесора на початку циклу обробки, номінальною інтенсивності супутнього інформаційного обміну, тривалості етапу гальмування процесора, тривалості етапу перемикання процесора:















6. Визначення значення такту процесора:





7. Визначення значення такту системної шини:




8. Визначення значення числа блоків даних, необхідного для передачі інформаційного слова з ВП в СОЗУ:







9. Визначення значення гранично допустимої довжини слова:





7.3 Висновок
Система реалізувати, тому що виконується умова:

менше


Глава 8. Розрахунок витрат на створення програмного забезпечення та оцінка техніко-економічної ефективності розробленого програмного забезпечення

Введення

У дипломному проекті розглядається актуальне завдання розробки системи обліку вагонів на під'їзній колії на підприємстві. Існуючі на вітчизняному ринку аналогічні вироби складні, дорогі і не вирішують всіх необхідних задач. Тому в дипломному проекті вирішувалося завдання розробки системи, що відрізняється порівняльною простотою використання і меншою вартістю при забезпеченні пред'являються до неї технічних вимог.
Рішення поставленої задачі неможливе без оцінки техніко-економічної ефективності системи, що розробляється.

8.1 Розрахунок витрат на розробку системи обліку комп'ютерного вагонів на під'їзній колії на підприємстві

Розрахунок витрат на розробку необхідний для обгрунтування економічної ефективності системи. Планові витрати на розробку включають всі витрати, пов'язані з її виконанням, незалежно від джерела їх фінансування. Визначення витрат на розробку виробляється шляхом складання калькуляції планової собівартості. Вона є основним документом, на підставі якого здійснюється планування і облік витрат на виконання.
Кошторис витрат включає такі статті:
- Основна заробітна плата розробників інформаційної системи;
- Додаткова заробітна плата розробників інформаційної системи;
- Відрахування на соціальні страхування;
- Розрахунок витрат на амортизацію ЕОМ;
- Витрати на електроенергію, яка використовується при розробці інформаційної системи;
- Накладні витрати.
Розглянемо детальніше кожну з зазначених статей витрат.

8.2 Розрахунок витрат на основну заробітну плату розробникам

Оплата праці являє сукупність коштів, виплачених працівникам у грошовій і натуральній формі як за відпрацьований час, виконану роботу, так і в установленому законодавством порядку за невідпрацьований час.
Нарахування основної заробітної плати проводиться в залежності від прийнятих на підприємстві форм оплати праці. При погодинній оплаті праці основна заробітна плата нараховується працівникам за фактично відпрацьований час, а при відрядній за фактично виконану роботу.
Погодинна форма оплати праці знаходить застосування при розрахунку заробітної плати робітників, службовців, фахівців і керівників. При цій формі оплати праці заробітна плата розраховується виходячи з місячного посадового окладу за пророблений час. Необхідно врахувати нарахування доплат за понаднормові роботи. Доплата нараховується понад погодинного заробітку з розрахунку 20% тарифної ставки робітника-повременщика.
Витрати на основну заробітну плату (Зосн.) при погодинній формі оплати праці розраховуються за формулою (7.1.):
Зосн .= Омес .* траба .* Кд / Др.мес., (7.1.)
де:
Омес. - Місячний оклад розробника програми;
Др.мес. - Середня кількість робочих днів у місяці;
Траба. - Фактичний час участі в розробці програми;
Кд - коефіцієнт, що враховує доплати до основної зарплати.
При цьому відношення Омес. / Др.мес. характеризує середню денну зарплату розробника.
Приймемо в нашому проекті:
Омес. керівника розробки програми = 7000 руб.
Омес. інженера - програміста = 5900 руб.
Омес. експерта = 3600 руб.
Др.мес. = 21 день;
Кд = 1.2.
Результати розрахунку витрат на основну заробітну плату розробників програми представлені у таблиці 8.1.
Таблиця 8.1.

8.3 Розрахунок додаткової заробітної плати розробників програми

У статті "Додаткова заробітна плата" плануються і враховуються виплати, передбачені законодавством про працю або колективними договорами за опрацьованим на виробництві (неявочное) час: оплата чергових і додаткових відпусток, компенсація за невикористану відпустку, оплата пільгових годин підліткам, оплата часу, пов'язаного з виконанням державних і громадських обов'язків та ін Вона визначається у відсотковому відношенні основної заробітної плати.
Здоп. = Кдоп. * Зосн. (8.2.)
де:
Кдоп. - Коефіцієнт, що враховує величину додаткової зарплати розробників програми. Приймемо Кдоп. рівним 0.25. На основі формули (7.2.) Визначаємо:
Здоп. = 0.25 * 28285.72 = 7071.43 руб.

8.4 Розрахунок відрахувань на соціальне страхування та забезпечення

Відповідно до законів Російської Федерації про пенсійне забезпечення, про зайнятість населення, про медичне страхування, про державне соціальне страхування працівників підприємств підлягають обов'язковому соціальному страхуванню і забезпеченню.
Відрахування на соціальне страхування включає в себе (у% до суми основної та додаткової заробітної плати):

соціальне страхування	7.9%
медичне страхування	6%
пенсійний фонд	14,0%
РАЗОМ:	27.9%

Таким чином, відрахування на соціальне страхування та забезпечення, що включаються до складу витрат на виробництво розраховують за формулою:
Ос.с.о. = Кс.с.о. * (Зосн. + Здоп.) (8.3.)
де:
Кс.с.о. - Коефіцієнт, що враховує відрахування до фонду соціального страхування, пенсійний фонд, медичного страхування. На підставі формули 7.3. визначаємо:
Ос.с.о. = 0.279 * (28285.72 + 7071.43) = 9864.65 руб.

8.5 Розрахунок витрат на амортизацію ЕОМ, використовуваних при розробці системи обліку комп'ютерного обладнання на підприємстві

Амортизація - це процес поступового зношування основних засобів і перенесення за встановленими нормами їх вартості на вироблену продукцію (роботи, послуги).
Нарахування за встановленими нормами амортизації основних засобів називається амортизаційними відрахуваннями. Норми амортизаційних відрахувань встановлені у відсотках до балансової (первісної) вартості основних засобів.
Норми амортизації можуть коригуватися в залежності від відхилень від нормативних умов використання основних засобів. Порядок їх нарахування визначено Єдиними нормами амортизаційних відрахувань на повне відновлення основних фондів народного господарства Російської Федерації, затвердженими постановою Ради Міністрів СРСР від 22 жовтня 1990 року N 1072.
Єдині норми амортизаційних відрахувань диференційовані залежно від нормативного терміну служби основних засобів. Термін служби (Тсл.) - величина, зворотна нормі амортизаційних відрахувань, являє собою відношення ста відсотків до норми амортизації:
Тсл .= 100/На (8.4.)
де:
На - норма амортизації в%.
Знос відображає моральний і фізичний стан об'єктів і є одним з критеріїв заміни їх на більш досконалі, продуктивні, комфортабельні види машин, обладнання та ін коштів.
Розрахунок витрат на амортизацію обладнання проводиться наступним чином:
Заст. = Спершу .* (На/100) * m * (tраб / Фд.о.) (8.5.)
де:
Спершу .- первісна вартість ЕОМ, використовуваної при розробці програми;
На - норма амортизаційних відрахувань;
m - кількість використовуваних ЕОМ;
tраб. - Час роботи ЕОМ;
Фд.о. - Дійсний річний фонд часу роботи ЕОМ.
Приймемо:
Спершу. = 18000 руб.,
На = 12.5%,
m = 1 шт.
tраб. = 30 днів * 8 год = 240 ч.,
Фд.о. = Кол.раб.дн. * Кол.смен * Продолж.смени =
= 252 дня * 1 зміна * 8 год = 2016 год
На основі формули (2.5) визначаємо:
Заступник .= 267.86 руб.
Результати розрахунку витрат на амортизацію ЕОМ, використовувані при розробці програми, представлені в таблиці 8.2.
Таблиця 8.2.

Найменування устаткування	Кількість одиниць обладнання m, шт	Час роботи обладнання tраб., Ч	Норма амортизаційних відрахувань,%	Витрати на амортизацію, руб.
IBM PC Pentium IV 1.4 Ггц	1	240	12.5	267.86

8.6 Розрахунок витрат на електроенергію, яка використовується ЕОМ у процесі розробки програми

Витрати на електроенергію (Зел.ен.) розраховуються за формулою: Зел.ен. = Це. * Р * m * tр (8.6.)
де:
Р - потужність ЕОМ, використовуваної при розробці програми;
tр - час роботи ЕОМ, що використовується при розробці програми;
m - кількість використовуваних ЕОМ;
Це. - Ціна 1 кВт * год електроенергії.
Приймемо:
Р = 300 Вт;
tp = 240 год;
m = 1 шт.;
Це. = 2.08 руб.
На основі формули визначаємо Зел.ен.:
Зел.ен. = 149.76 руб.
Результати розрахунку витрат на електроенергію, яка використовується в процесі розробки програми, представлені в таблиці 8.3.

Таблиця 8.3.

Найменування устаткування	Кількість одиниць обладнання m, шт	Час роботи обладнання tр., Ч	Потужність обладнання, кВт	Витрати на електро-енергію, руб.
IBM PC Pentium IV 1.4 Ггц	1	240	0.30	149.76

8.7 Розрахунок накладних витрат

До статті "Накладні витрати" включаються витрати на управління і господарське обслуговування. За цією статтею враховується заробітна плата апарату управління і загальногосподарських служб, витрати на утримання та поточний ремонт будівель, споруд, обладнання та інвентарю, амортизаційні відрахування на їхнє повне відновлення і капітальний ремонт, витрати по охороні праці, науково-технічної інформації, винахідництва та раціоналізації. Величина накладних витрат визначається у відсотках від основної і додаткової заробітної плати.
Накладні витрати (Рнакл.) розраховуються за формулою:
Рнакл. = Кн * (Зосн. + Здоп.) (8.7.)
де:
Кн - коефіцієнт накладних витрат. Приймемо Кн рівним 0.7. На основі формули (7.7.) Визначаємо:
Рнакл. = 0.7 * (28285.72 + 7071.43) = 24750.01 руб.
Результати розрахунку витрат на розробку системи обліку комп'ютерного обладнання на підприємстві зведемо в таблицю 8.4.
Таблиця 8.4. Кошторис витрат на розробку системи обліку комп'ютерного обладнання на підприємстві

8.8 Розрахунок витрат на експлуатацію системи обліку комп'ютерного обладнання на підприємстві

Метою розрахунку витрат на експлуатацію є отримання необхідних даних для визначення річного економічного ефекту від впровадження розробленої системи обліку вагонів на під'їзній колії на підприємстві. У витрати на експлуатацію розробленої системи включаються всі витрати, пов'язані з її експлуатацією протягом року.
Кошторис витрат включає такі статті:
- Основна заробітна плата обслуговуючого персоналу системи обліку комп'ютерного обладнання на підприємстві;
- Додаткова заробітна плата обслуговуючого персоналу системи;
- Відрахування на соціальні страхування;
- Розрахунок витрат на амортизацію ЕОМ;
- Витрати на електроенергію, яка використовується при експлуатації інформаційної системи;
- Накладні витрати.
При розрахунках використовуємо ті ж формули, що і в попередньому розділі.
Приймемо в нашому проекті:
Омес. керівника розробки програми = 7000 руб.
Омес. системного інженера, який здійснює експлуатацію інформаційної системи = 5900 руб.
Др.мес. = 21 день;
Кд = 1.2.
Результати розрахунку витрат на основну заробітну плату обслуговуючого персоналу інформаційної системи представлені в таблиці 7.5.
Таблиця 8.5.

Обслуговуючий Персонал	Час роботи, днів	Середня денна зарплата Омес. / Др.мес, руб.	Витрати на зарплату, руб.
Системний інженер	231	280.95	77880
Разом			77880

Розрахунок додаткової заробітної плати обслуговуючого персоналу програми.
Здоп. = 0.25 * 77880 = 19470 руб.
Розрахунок відрахувань на соціальне страхування та забезпечення.
Ос.с.о. = 0.279 * (77880 + 19470) = 27160.65 руб.
Розрахунок витрат на амортизацію ЕОМ, використовуваних при експлуатації системи обліку комп'ютерного обладнання на підприємстві.
Приймемо:
Спершу. = 15000 руб.,
На = 12.5%,
m = 6 шт.,
tраб. = 231 день * 8 год = 1848 год,
Фд.о. = 2016 год
На основі формули (1.5.) Визначаємо:
Заступник .= 10312.5 руб.
Результати розрахунку витрат на амортизацію ЕОМ, використовувані при розробці програми, представлені в таблиці 8.6.
Таблиця 8.6.

Найменування устаткування	Кількість одиниць обладнання m, шт	Час роботи обладнання tраб., Ч	Норма амортизаційних відрахувань,%	Витрати на амортизацію, руб.
CELERON 1.7 Ггц	6	1848	25	10312.5

Розрахунок витрат на електроенергію, яка використовується ЕОМ у процесі експлуатації програми.
Приймемо:
Р = 300 Вт; tp = 1848 год; m = 6;
Це. = 1.24 руб.
На основі формули (1.6.) Визначаємо Зел.ен.:
Зел.ен. = 4124.74 руб.
Результати розрахунку витрат на електроенергію, яка використовується в процесі експлуатації програми, представлені в таблиці 8.7.
Таблиця 8.7.

Найменування устаткування	Кількість одиниць обладнання m, шт	Час роботи обладнання tр., Ч	Потужність обладнання, кВт	Витрати на електро-енергію, руб.
CELERON 1.7 Ггц	6	1848	0.3	4124.74

Розрахунок накладних витрат.
Рнакл. = 0.7 * (77880 + 19470) = 68145 руб.
Результати розрахунку витрат на експлуатацію системи обліку комп'ютерного обладнання на підприємстві зведемо в таблицю 8.8.
Таблиця 8.8. Кошторис витрат на експлуатацію системи обліку комп'ютерного обладнання на підприємстві

8.9 Розрахунок відпускної ціни розроблюваної системи обліку комп'ютерного обладнання на підприємстві

Відпускна ціна розроблюваної системи обліку комп'ютерного обладнання на підприємстві визначається як сума повної собівартості, планованого прибутку та ПДВ.
Планована прибуток становить 15% від повної собівартості.
ПДВ становить 18% від суми повної собівартості і планованого прибутку.
ОЦ = Сполн. + Пр.пл. + ПДВ = 70389.43 +10558.41 +12670.1 = 93617.94 руб.

8.10 Розрахунок окупності капітальних вкладень

Розрахунок окупності КВ здійснюється за формулою:
Струм = КВ / (Пр.пл. * N)
де Ток - термін окупності;
КВ - капітальні вкладення;
Пр.пл. - Планований прибуток;
N - запланований річний обсяг продажів, шт.
Капітальні вкладення рівні витрат на розробку і складають:
КВ = Сполн. = 70389.43 руб.,
Струм = 70389.43 / (10558.41 * 20) = 0.33 року
Висновок
Таким чином, в цьому розділі розглянуті питання організаційно-економічного обгрунтування процесу розробки та виготовлення системи обліку вагонів на під'їзній колії на підприємстві. Представлені оцінки одноразових і капітальних витрат, часу окупності розробки, розрахунок основної та додаткової заробітної плати, відрахування до фонду соціального страхування.

Глава 9. Екологічна частина

Досягнення науки і техніки, бурхливий розвиток науково-технічної революції, що впливають на всю сферу людської діяльності, вимагають подальшого удосконалення управління, стилю і методів роботи, підвищення якості та ефективності управлінської праці.
Механізація і автоматизація праці вимагають від людей постійного підвищення своєї ділової кваліфікації, більш глибоких знань високих технологій.
Широке поширення мікроелектроніки, комп'ютерів індивідуального користування, потужних засобів автоматизованої обробки тексту і графічної інформації, високо ефективних пристроїв її зберігання та пошуку, сучасних засобів зв'язку та мереж електронно-обчислювальних машин дозволяють деяким фахівцям ставити питання про перспективи створення електронних офісів майбутнього.
Робота операторів, програмістів і просто користувачів безпосередньо пов'язана комп'ютерами, а відповідно з шкідливими впливами цілої групи факторів, що істотно знижує продуктивність їх праці.
Вивчення та розв'язання проблем, пов'язаних із забезпеченням здорових та безпечних умов, в яких протікає праця людини - одна з найбільш важливих завдань у розробці нових технологій і систем виробництва. Вивчення і виявлення можливих причин виробничих нещасних випадків, професійних захворювань, аварій, вибухів, пожеж, і розробка заходів та вимог, спрямованих на усунення цих причин дозволяють створити безпечні і сприятливі умови для праці людини.

9.1 Вимоги до умов експлуатації обчислювальної техніки (ОТ)

9.1.1 Вимоги до приміщень для експлуатації ЗТ

1. Приміщення для експлуатації ВТ повинні мати природне і штучне освітлення. У випадках виробничої необхідності експлуатація ОТ у приміщеннях без природного освітлення може проводитися тільки за погодженням з органами Державного санітарно-епідеміологічного нагляду.
2. Природне освітлення повинно забезпечувати коефіцієнт природної освітленості (КПО) не нижче 1,2% у зонах зі стійким сніжним покривом і не нижче 1,5% на решті території. Вікна в приміщеннях, де експлуатується обчислювальна техніка, переважно повинні бути орієнтовані на північ і північний схід.
3. Площа на одне робоче місце для дорослих користувачів ВТ повинна становити не менше 6,0 кв. м., а обсяг не менше 20,0 куб. м.
4. Для внутрішнього оздоблення приміщень з ВТ повинні використовуватися дифузно-відбивні матеріали з коефіцієнтами відбиття для стелі - 0,7-0,8; для стін - 0,5-0,6; для підлоги - 0,3-0,5.
5. Поверхня підлоги в приміщеннях експлуатації ЗТ повинна бути рівною, без вибоїн, неслизькою, зручною для очищення і для вологого прибирання, мати антистатичні властивості.
6. Приміщення, де експлуатується ВТ, мають бути обладнані системами опалення, кондиціонування повітря або припливно-витяжною вентиляцією.
7. ВТ повинна мати заземлення відповідно до технічних вимог з її експлуатації.
8. Звукоізоляція огороджувальних конструкцій приміщень, де розташована ВТ, повинна забезпечувати параметри шуму.

9.1.2 Вимоги до освітлення приміщень та робочих місць користувачів ВТ
1. При роботі з ОТ, як правило, застосовується природне освітлення. Бажано, щоб світлові прорізи розташовувалися зліва від користувача ВТ, допускається і правосторонній природне освітлення. У тих випадках, коли одного природного освітлення не вистачає, встановлюється суміщене освітлення. При цьому додаткове штучне освітлення застосовується не тільки в темний, але і в світлий час доби. Нормовані значення освітленості при природному і суміщеному освітленні наведені у таблиці 9.1.
Таблиця 9.1. Значення освітленості при природному і штучному освітленні
2. Штучне освітлення в приміщеннях експлуатації ЗТ має здійснюватись системою загального рівномірного освітлення. Допускається використання місцевого освітлення, призначеного для освітлення зони розташування документів.
3. Слід обмежувати пряму блесткость від джерел освітлення, при цьому яскравість світяться поверхонь (вікна, світильники тощо), що знаходяться в полі зору, не повинна бути більше 200 кд / кв.м.
4. Слід обмежувати нерівномірність розподілу яскравості в полі зору в поле зору користувача ВТ, при цьому співвідношення яскравості між робочими поверхнями не повинно перевищувати 3:1 - 5:1, а між робочими поверхнями і поверхнями стін і обладнання 10:1.
5. Освітленість на поверхні столу в зоні розміщення робочого документу повинна бути 300 - 500 лк. Допускається установка світильників місцевого освітлення для підсвічування документів. Місцеве освітлення не повинно створювати відблисків на поверхні екрана, а освітленість екрана має не перевищувати 300 лк.
6. Слід обмежувати відбиту блесткость на робочих поверхнях за рахунок правильного вибору типів світильників та розташування робочого місця по відношенню до джерел штучного освітлення. Яскравість відблисків на екрані ЗТ нічого не повинна перевищувати 40 кд / кв.м, яскравість стелі, при застосуванні системи відбитого освітлення, не повинна перевищувати 200 кд / кв.м.
7. Рекомендоване освітлення для роботи з екраном дисплея складає 200 лк, а при роботі з екраном в поєднанні з роботою над документами - 400 лк. Рекомендовані яскравості в полі зору операторів повинні лежати в межах 1:5 - 1:10.
8. В якості джерел світла при штучному освітленні повинні застосовуватися переважно люмінесцентні лампи типу ЛБ. При влаштуванні відбитого освітлення в адміністративно-громадських приміщеннях допускається застосування металогалогенних ламп потужністю до 250 Вт. Допускається застосування ламп розжарювання у світильниках місцевого освітлення. Найбільш прийнятними є люмінесцентні лампи білого і тепло-білого світла.
9. Загальне освітлення слід виконувати у вигляді суцільних або переривчастих ліній світильників, розташованих збоку від робочих місць, паралельно лінії зору користувача при рядном розташуванні Вт При периметральном розташуванні комп'ютерів лінії світильників повинні розташовуватися локалізовано над робочим столом, ближче до його переднього краю, зверненого до користувача Вт
10. Яскравість світильників загального освітлення в зоні кутів випромінювання від 50 до 90 градусів з вертикаллю в поздовжній і поперечній площинах повинна складати не більше 200 кд / кв.м, захисний кут світильників повинен бути не менше 40 градусів.
11. Світильники місцевого освітлення повинні мати не просвічує відбивач із захисним кутом не менше 40 градусів.
12. Коефіцієнт запасу для освітлювальних установок загального освітлення має прийматися 1.4.
13. Коефіцієнт пульсації не повинен перевищувати 5%, що повинне забезпечуватися застосуванням газорозрядних ламп у світильниках загального та місцевого освітлення з високочастотними пускорегулювальними апаратами (ВЧ ПРА) для будь-яких типів світильників. При відсутності світильників з ВЧ ПРА лампи багатолампових світильників або поруч розташовані світильники загального освітлення вмикати на різні фази трифазної мережі.
14. Для забезпечення нормованих значень освітленості в приміщеннях використання ВТ слід проводити чистку стекол віконних рам і світильників не рідше двох разів на рік і проводити своєчасну заміну перегорілих ламп.

9.1.3 Вимоги до шуму і вібрації в приміщеннях експлуатації ЗТ

1. Шум створюють системний блок, а точніше блок живлення в системному блоці - менше 40 дБА (один метр від поверхні), джерело безперебійного живлення - менше 40 дБА, принтер - менше 40 дБА. При виконанні основної роботи в приміщеннях для експлуатації ЗТ, рівень шуму не повинен перевищувати 60 дБА.
2. У приміщеннях користувачів ВТ рівень шуму не повинен перевищувати 65 дБА.
3. На робочих місцях у приміщеннях для розміщення гучних агрегатів обчислювальних машин (АЦПУ, принтери та ін) рівень шуму не повинен перевищувати 75 дБА.
4. Шумляче устаткування (АЦПУ, принтери та ін), рівні шуму якого перевищують нормовані, повинне знаходиться поза приміщенням з Вт
5. Знизити рівень шуму в приміщеннях з ВТ можна використанням звуковбирних матеріалів з максимальними коефіцієнтами звукопоглинання в області частот 63-8000 Гц для обробки приміщень (дозволених органами й установами держсанепіднагляду Росії), підтверджених спеціальними акустичними розрахунками.
6. Додатковим звукопоглинанням служать однотонні фіранки з щільної тканини, що гармоніюють з фарбуванням стін і підвішені в складку на відстані 15 - 20 см від огорожі. Ширина фіранки повинна бути в 2 рази більше ширини вікна.

9.1.4 Вимоги до мікроклімату, змісту аероіонів і шкідливих хімічних речовин в повітрі приміщень експлуатації ЗТ

1. Для підтримання параметрів мікроклімату необхідно використовувати системи кондиціонування повітря, оскільки робота ВТ призводить до підвищення температури в приміщенні і пониження вологості повітря, так як ВТ працює на надвисоких частотах, що викликає сильне нагрівання елементів. У виробничих приміщеннях, в яких робота з ВТ є основною, повинні забезпечуватися оптимальні параметри мікроклімату, представлені в таблиці 9.2.

Таблиця 9.2. Оптимальні норми мікроклімату приміщень
Примітки: до категорії 1а відносяться роботи, вироблені сидячи і не потребують фізичної напруги, при яких витрата енергії складає до 120 ккал / год; до категорії 1б належать роботи, вироблені сидячи, стоячи або пов'язані з ходьбою і супроводжуються деяким фізичним напруженням, при яких витрата енергії становить від 120 до 150 ккал / ч.
2. Для підвищення вологості повітря в приміщеннях з ВТ слід застосовувати зволожувачі повітря, що заправляють щодня дистильованої або кип'яченої питною водою. У приміщенні щодня повинна проводитися вологе прибирання.
3. До шкідливих речовин, які діють в приміщенні з ВТ, відносяться пил і виділення парів спирту після профілактичного чищення Вт Концентрація пилу в повітрі повинна не перевищувати 0.5 мг / куб.м. Для зниження ступеня запилення приміщення, необхідно регулярно провітрювати і здійснювати прибирання пилу приміщень.
4. Висока напруга на струмоведучих частинах схеми (15кВ) викликають іонізацію повітря з утворенням позитивних іонів, які несприятливо впливають на людину. У 1куб.см повітря міститься число позитивних іонів у діапазоні від 200 до 6000. Впливу іонізуючого випромінювання користувач піддається в процесі роботи, перебуваючи в безпосередній близькості від монітора. При дотриманні необхідної відстані між джерелом іонізуючих випромінювань і користувачем ВТ вплив іонізуючого випромінювання на організм можна звести до мінімуму. Рівні іонізації повітря приміщень представлені в таблиці 9.3.
Таблиця 9.3. Рівні іонізації повітря приміщень при експлуатації ЗТ

Рівні	Число іонів в 1 см куб. повітря
	n +	n-
Мінімальні	400	600
Оптимальні	1500 - 3000	300 - 5000
Максимально допустимі	50000	50000

9.1.5 Вимоги до рівнів електромагнітних полів в приміщеннях експлуатації ЗТ

1. Приміщення, обладнані ВТ, не допускається розміщувати поблизу джерел електромагнітних полів (ЕМП) промислової частоти 50 Гц (силові кабелі, трансформаторні підстанції та ін.)
2. У приміщеннях при організації робочих місць, обладнаних моніторами (відео термінальними пристроями - ВДТ), необхідно проводити вимірювання фонових рівнів ЕМП промислової частоти 50 Гц. При цьому напруженість електричного поля повинна бути не більше не більше 500 В / м.
3. У виробничих приміщеннях при виконанні основних чи допоміжних робіт на робочих місцях, обладнаних ЗТ, експлуатація ВТ повинна здійснюватися при рівнях ЕМП, що не перевищують гранично допустимі значення, представлених у таблиці 9.4.
Таблиця 9.4. Гранично допустимі рівні (ПДУ) ЕМП

Найменування параметрів	ПДУ
Напруженість електростатичного поля	15 кВ / м
Напруженість електричного поля промислової частоти (50 Гц)	500 В / м
Індукція / напруженість магнітного поля промислової частоти (50 Гц)	10мкТл/8А/м
Напруженість електричного поля в діапазоні частот 0,03 - 300 МГц	3 В / м

4. Вимірювання рівнів ЕМП на робочому місці користувача і в місцях експлуатації ЗТ проводяться на відстані не менше 50 см від екрана на трьох рівнях: 0,5 м; 1 мі 1,4 м від підлоги, не раніше, ніж через 20 хвилин після включення Вт При цьому на екрані ВДТ має бути типове для даного виду роботи зображення (текст, графіки та ін.) При проведенні вимірювань повинна бути включена вся обчислювальна техніка, ВДТ та інше використовується для роботи електрообладнання, розміщене в даному приміщенні.
5. При перевищенні ПДУ ЕМП на робочому місці користувача і в місцях експлуатації ЗТ у разі відсутності санітарно-епідеміологічного висновку на даний тип ОТ або сумніви в якості ВТ, на розсуд санітарного лікаря, можливе проведення вимірювань параметрів ЕМП Вт
6. Інструментальний контроль стану робочих місць користувачів та місць експлуатації ЗТ, слід проводити при введенні ОТ в експлуатацію, а потім 1 раз на 2 роки силами лабораторій, акредитованих у встановленому порядку.

9.2 Вимоги до організації та обладнання робочих місць користувачів і місць експлуатації ЗТ

1. Схеми розміщення робочих місць з ВТ повинні враховувати відстані між робочими столами з відеомоніторами (у напрямі тилу поверхні одного відеомонітора і екрану іншого відеомонітора), яка повинна бути не менше 2,0 м, а відстань між бічними поверхнями відеомоніторів - не менше 1,2 м .
2. Робочі місця з ОТ у приміщеннях з джерелами шкідливих виробничих факторів повинні розміщуватися в ізольованих кабінах з організованим повітрообміном.
3. Віконні отвори в приміщеннях, де експлуатується ВТ, повинні бути обладнані регульованими пристроями типу: жалюзі, фіранок, зовнішніх козирків і ін
4. Робочі місця з ВТ під час творчої роботи, що вимагає значного розумового напруження або високої концентрації уваги, рекомендується ізолювати один від одного перегородками висотою 1,5 - 2,0 м.
6. При конструюванні устаткування та організації робочого місця користувача ВТ слід забезпечити відповідність конструкції всіх елементів робочого місця та їх взаємного розташування ергономічним вимогам з урахуванням характеру виконуваної користувачем діяльності, комплектності технічних засобів, форм організації праці та основного робочого стану користувача.
7. Характеристики використовуваного робочого місця:
- Висота робочої поверхні столу 750 мм;
- Висота простору для ніг 650 мм;
- Висота сидіння над рівнем підлоги 450 мм;
- Поверхня сидіння м'яка з закругленим переднім краєм;
- Передбачена можливість розміщення документів праворуч і ліворуч;
- Відстань від ока до екрана 700 мм;
- Відстань від ока до клавіатури 400 мм;
- Відстань від ока до документів 500 мм;
- Можливе регулювання екрана по висоті, по нахилу, у лівій і в правому напрямках.
8. Правильна установка робочого столу:
- При фіксованій висоті - найкраща висота - 72 см;
- Повинен забезпечуватися необхідний простір для рук по висоті, ширині і глибині;
- В області сидіння не повинно бути шухляд столу.

Таблиця 9.5. Висота одномісного столу для занять з ВТ

Зростання людини у взутті, см	Висота над підлогою, мм
	поверхню столу	простір для ніг не менш
116 - 130	520	400
131 - 145	580	520
146 - 160	640	580
161 - 175	700	640
вище 175	760	700

Примітка: ширина і глибина простору для ніг визначаються конструкцією столу.
9. Правильна установка робочого стільця:
- Висота повинна регулюватися;
- Конструкція повинна бути обертається;
- Правильна висота сидіння: площа сидіння на 3 см нижче, ніж підколінна западина.
10. Конструкція монітора повинна забезпечувати можливість фронтального спостереження екрана шляхом повороту корпуса в горизонтальній площині навколо вертикальної осі в межах ± 30 ° і у вертикальній площині навколо горизонтальної осі в межах ± 30 ° з фіксацією в заданому положенні.
11. Дизайн моніторів повинен передбачати фарбування в спокійні м'які тони з дифузійним розсіюванням світла.
12. Корпус монітора і ПЕОМ, клавіатура повинні мати матову поверхню одного кольору з коефіцієнтом відображення 0,4 - 0,6 і не мати блискучих деталей, здатних створювати відблиски.
13. Конструкція ВДТ повинна передбачати наявність ручок регулювання яскравості і контрасту, що забезпечують можливість регулювання яскравості і контрасту, що забезпечують можливість регулювання цих параметрів від мінімальних до максимальних значень.
14. Конструкція клавіатури повинна передбачати:
- Виконання у вигляді окремого пристрою з можливістю вільного переміщення;
- Опорне пристосування, що дозволяє змінювати кут нахилу поверхні клавіатури у межах від 5 ° до 15 °;
- Висоти середнього ряду клавіш не більше 30 мм;
- Розташування часто використовуваних клавіш в центрі, внизу і праворуч, рідко використовуваних - вгору і вліво;
- Виділення кольором, розміром формою і місцем розташування функціональних груп клавіш;
- Мінімальний розмір клавіш - 13 мм, оптимальний - 15 мм;
- Клавіші з заглибленням у центрі і кроком 19 ± 1 мм;
- Відстань між клавішами не менше 3 мм;
- Однаковий хід для всіх клавіш з мінімальним опором натисканню 0,25 Н та максимальної - не більше 1,5 Н;
- Звукову зворотний зв'язок від включення клавіш з регулюванням рівня звукового сигналу і можливістю його відключення.

9.3 Загальні рекомендації до організації праці та відпочинку при роботі з ВТ

1. Режим праці та відпочинку операторів безпосередньо працюють з ВДТ, повинен залежати від характеру виконуваної роботи: при введенні даних, редагуванні програм, читанні інформації з екрана. Безперервна тривалість роботи з ЗТ нічого не повинна перевищувати 4-х годин при 8-ми годинному робочому дні.
2. При 8-ми годинний робочій зміні основним перервою є перерва на обід. Додатково при роботі з ВТ вводяться регламентовані перерви: - для 1-ої категорії робіт (робота з зчитування інформації з екрана ВДТ або ПЕОМ з попереднім запитом) через 2 години від початку робочої зміни і через 2 години після обідньої перерви тривалістю 15 хвилин кожний; - для 2-ої категорії робіт (робота з введення інформації) через 2 години від початку робочої зміни і 1.5-2.0 години після обідньої перерви тривалістю 15 хвилин кожен або тривалістю 10 хвилин через кожну годину роботи; - для 3-ої категорії робіт (творча робота в режимі діалогу з ПЕОМ) через 1.5-2.0 години з початку робочої зміни і 1.5-2.0 години після обідньої перерви тривалістю 20 хвилин кожен або тривалістю 15 хвилин через кожну годину роботи.
Таблиця 9.6. Час регламентних перерв у залежності від тривалості робочої зміни, виду і категорії трудової діяльності з ВТ

Категорія роботи з ВТ	Рівень навантаження за робочу зміну при видах робіт з ВДТ			Сумарний час регламентованих перерв, мін
	група А, кількість знаків	група Б, кількість знаків	група В, годину	при 8 - ми годинній зміні	при 16 - ми годинній зміні
I	до 20.000	до 15.000	до 2.0	30	70
II	до 40.000	до 30.000	до 4.0	50	90
III	до 60.000	до 60.000	до 6.0	70	120

Примітка: Час перерв дано при дотриманні вимог Санітарних правил і норм. У разі невідповідності фактичних умов праці вимогам цих санітарних правил і норм, час регламентованих перерв слід збільшити на 30%.
3. Тривалість безперервної роботи з ВТ без регламентованого перерви має перевищувати 2-х годин.
4. Користувачі ОТ у виробничих умовах повинні проходити обов'язкові попередні (при вступі на роботу) і періодичні медичні огляди в порядку і в строки, встановлені Міністерством охорони здоров'я Росії.
5. До безпосередньої роботи з ВТ допускаються особи, які не мають медичних протипоказань.
6. Жінки з часу встановлення вагітності до виконання всіх видів робіт, пов'язаних з використанням ЗТ, не допускаються. Працевлаштування вагітних жінок слід здійснювати відповідно до "Гігієнічними рекомендаціями щодо раціонального працевлаштування вагітних жінок". [15]

Висновок
У даній дипломній роботі стояла задача розробки БД з обліку вагонів на під'їзній колії підприємства.
У процесі виконання дипломної роботи були досягнуті наступні результати:
спроектована концептуальна модель баз даних;
спроектована логічна модель з урахуванням нормалізації і цілісності даних;
здійснена вибірка СУБД і побудована фізична модель, з визначенням полів і типів даних;
обраний комплекс технічних засобів;
реалізовані основні програмні модулі системи;
На підставі отриманих матеріалів була розроблена інформаційно-довідкова система з обліку вагонів на під'їзній колії підприємства. Дана система направлена ​​на автоматизацію процесу обробки інформації по вагонах, а також для розрахунку витрат на обслуговування рухомого складу.

Список літератури
1. Вендров А.М. Проектування програмного забезпечення економічних інформаційних систем, Фінанси і статистика, М, 2002 р.
2. Гері Хансен, Джеймс Хансен. Бази даних. Розробка і керування, Біном, М, 2001 р.
3. Джен Л. Харрінгтон. Проектування реляційних баз даних Лорі, 2006 р.
4. Джеффрі Д. Ульман, Дженніфер Уідом. Основи реляційних баз даних, Лорі, М, 2006 р.
5. Кен Хендерсон. Професійний посібник з SQL Server. Структура і реалізація (+ CD-ROM), Вільямс, М, 2006 р.
6. Міністерство охорони здоров'я Російської Федерації. Гігієнічні вимоги до обчислювальної техніки, умов і організації роботи, М, 2002 р.
7. Пітер Роб, Карлос Коронел. Системи баз даних: проектування, реалізація і управління, БХВ-Петербург, Сп-б, 2004 р.
8. Сорокін А.В. Розробка баз даних, Пітер, Сп-б, 2005 р.
9. Томас Конноллі, Каролін Бегг, Ганна Страчан. Бази даних. Проектування, реалізація й супровід. Теорія і практика, Вільямс, М, 2001 р.
10. Шкриль А.А. Розробка клієнт-серверних додатків в Delphi, БХВ-Петербург, Сп-б, 2006 р.
11. Елісон Балтер. Професійне програмування в Microsoft Office Access 2003 (+ CD-ROM), Вільямс, М, 2006 р.

Додаток 1

Лістинг програми
unit Unit1;
interface
uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
Dialogs, Menus, ActnList, StdCtrls, Grids, DBGrids, OleServer, AccessXP, Qt {, QDialogs};
type
TForm1 = class (TForm)
MainMenu1: TMainMenu;
PopupMenu1: TPopupMenu;
ActionList1: TActionList;
N1: TMenuItem;
N3: TMenuItem;
GroupBox1: TGroupBox;
DBGrid1: TDBGrid;
add: TAction;
edit: TAction;
del: TAction;
N16: TMenuItem;
N17: TMenuItem;
N18: TMenuItem;
N2: TMenuItem;
N4: TMenuItem;
N10: TMenuItem;
N11: TMenuItem;
N12: TMenuItem;
procedure FormShow (Sender: TObject);
procedure addExecute (Sender: TObject);
procedure editExecute (Sender: TObject);
procedure delExecute (Sender: TObject);
procedure N4Click (Sender: TObject);
procedure N12Click (Sender: TObject);
procedure N10Click (Sender: TObject);
procedure DBGrid1KeyDown (Sender: TObject; var Key: Word;
Shift: TShiftState);
procedure N7Click (Sender: TObject);
procedure N2Click (Sender: TObject);
private
{Private declarations}
public
{Public declarations}
end;
var
Form1: TForm1;
implementation
uses Unit3, Unit4, Unit5, Unit2, Unit6, Unit7, Unit9;
{$ R *. dfm}
procedure TForm1.FormShow (Sender: TObject);
begin
Tbl: = 'Vagon';
ShowZapros;
end;
procedure TForm1.addExecute (Sender: TObject);
begin
Form6.Caption: = 'Інформація по вагону';
Tbl: = 'Vagon';
ForEdit: = '-1';
Form6.ShowModal;
if ((EditMode = false) and (EditIns)) then
begin
EditMode: = true;
Form6.ShowModal;
end;
end;
procedure TForm1.editExecute (Sender: TObject);
begin
if (DataModule2.QShow ['V.id'] = Null) then
begin
ShowMessage ('Нема чого редагувати');
EditMode: = false;
end
else
begin
EditMode: = True;
Form6.ShowModal;
end;
end;
procedure TForm1.delExecute (Sender: TObject);
begin
if (DataModule2.QShow ['V.id'] = Null) then
begin
ShowMessage ('Нема чого видаляти');
EditMode: = false;
end
else
begin
Tbl: = 'Vagon';
pole1: = 'id';
pole2: = 'mymonth';
pole3: = 'myyear';
pole4: = 'nomer_vagona';
pole5: = 'invent_nomer';
pole6: = 'year_izgot';
pole7: = 'gruzopodemnost';
pole8: = 'liter';
pole9: = 'key_rod_vagona';
pole10: = 'iznos';
pole11: = 'prinadlezhnost';
pole12: = 'key_raion_dvizh';
pole13: ='';
ForDel: = DataModule2.QShow ['v.id'];
DelZapros;
ShowZapros ();
end;
end;
procedure TForm1.N4Click (Sender: TObject);
begin
ShowMessage ('Бурцева Катерина');
end;
procedure TForm1.N12Click (Sender: TObject);
begin
Form1.Close;
end;
procedure TForm1.N10Click (Sender: TObject);
begin
ForReport ();
Form9.ShowModal;
end;
procedure TForm1.DBGrid1KeyDown (Sender: TObject; var Key: Word;
Shift: TShiftState);
var InputString: string;
begin
if ([ssCtrl] = Shift) and (key = key_F) then
begin
InputString: = InputBox ('Пошук', 'Введіть інвентарний номер:','');
if InputString <>''then
begin
if not DataModule2.QShow.Locate ('invent_nomer', InputString, []) then
begin
showmessage ('Запис не знайдено');
end;
end;
end;
end;
procedure TForm1.N7Click (Sender: TObject);
begin
{For MyI: = 0 to Form9.StringGrid1.RowCount-1 do
begin
Form9.StringGrid1.Cells [0, MyI]: = Form1.DBGrid1.Columns [MyI]. Title.Caption;
end;}
{For tmpI: = 0 to 10 do
Form9.StringGrid1.Cells [1, tmpI]: ='';}
{Form9.StringGrid1.Enabled: = true;
Form9.Button1.Enabled: = true;
Form9.Button1.Caption: = 'Шукати';
Form9.ShowModal ();}
end;
procedure TForm1.N2Click (Sender: TObject);
begin
winhelp (Form1.Handle, 'help.hlp', HELP_CONTEXT, 1);
end;
end.

unit Unit2;
interface
uses
SysUtils, Classes, DB, ADODB;
type
TDataModule2 = class (TDataModule)
ADOConnection1: TADOConnection;
Query1: TADOQuery;
DS1: TDataSource;
QShow: TADOQuery;
DSshow: TDataSource;
Qtmp: TADOQuery;
DStmp: TDataSource;
QOSV: TADOQuery;
DSOSV: TDataSource;
Quslugi: TADOQuery;
DSuslugi: TDataSource;
QSelUs: TADOQuery;
DSselUs: TDataSource;
QueryRep: TADOQuery;
DSQueryRep: TDataSource;
ADOQuery1: TADOQuery;
DataSource1: TDataSource;
private
{Private declarations}
public
{Public declarations}
end;
var
DataModule2: TDataModule2;
implementation
{$ R *. dfm}
end.
unit Unit3;
interface
uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
Dialogs, StdCtrls, Grids, DBGrids, Menus, ActnList;
type
TForm3 = class (TForm)
GroupBox1: TGroupBox;
DBGrid1: TDBGrid;
Edit1: TEdit;
Button1: TButton;
Label1: TLabel;
Edit2: TEdit;
Label2: TLabel;
ActionList1: TActionList;
PopupMenu1: TPopupMenu;
del: TAction;
N1: TMenuItem;
procedure Button1Click (Sender: TObject);
procedure DBGrid1DblClick (Sender: TObject);
procedure FormShow (Sender: TObject);
procedure delExecute (Sender: TObject);
procedure FormClose (Sender: TObject; var Action: TCloseAction);
procedure DBGrid1CellClick (Column: TColumn);
private
{Private declarations}
public
{Public declarations}
end;
var
Form3: TForm3;
implementation
Uses Unit2, Unit4;
{$ R *. dfm}
procedure TForm3.Button1Click (Sender: TObject);
begin
If (tbl = 'Ceha') then
begin
ToIns2: = Edit2.Text;
end;
ToIns: = Edit1.Text;
InsertZapros ();
ShowZapros ();
Edit1.Clear;
Edit2.Clear;
end;
procedure TForm3.DBGrid1DblClick (Sender: TObject);
begin
SelTab ();
Form3.Close;
end;
procedure TForm3.FormShow (Sender: TObject);
begin
Edit1.SetFocus;
Edit1.Clear;
Edit2.Clear;
If (tbl = 'Ceha') then
begin
Edit2.Visible: = True;
Edit1.Width: = 161;
Label2.Visible: = True;
end
else
begin
Edit1.Width: = 225;
Edit2.Visible: = False;
Label2.Visible: = False;
end;
end;
procedure TForm3.delExecute (Sender: TObject);
begin
ForDel: = DataModule2.Query1 ['id'];
DelZapros;
ShowZapros ();
Edit1.Clear;
Edit2.Clear;
end;
procedure TForm3.FormClose (Sender: TObject; var Action: TCloseAction);
begin
InsEdit: = false;
ForEdit: = '-1';
end;
procedure TForm3.DBGrid1CellClick (Column: TColumn);
begin
If (Tbl = 'Ceha') then
begin
Edit2.Text: = SelectQ [pole3];
end;
Edit1.Text: = SelectQ [pole2];
ForEdit: = SelectQ [pole1];
InsEdit: = True;
end;
end.

unit Unit4;
interface
Uses ADODB;
var QueryString, TBL, pole1, pole2, Pole3, pole4, Pole5, pole6: string;
pole7, pole8, pole9, pole10, pole11, pole12, pole13: string;
ToIns, ToIns2, ToIns3, ToIns4, ToIns5, ToIns6, ToIns7, ToIns8: string;
ToIns9, ToIns10, ToIns11, ToIns12, ToIns13, ForDel, ForEdit, ForOrder, Diap, TmpFiltr: string;
InsEdit, InsEdit2, InsEdit3, InsEdit4, InsEdit5: boolean;
SelectQ: TADOQuery;
EditMode, ForSort, ForFiltr, EditMode2, EditMode3, EditMode4, EditIns, EditIns2: boolean;
Procedure ShowZapros ();
Procedure InsertZapros ();
Procedure DelZapros ();
Procedure SelTab ();
Procedure ForReport ();
implementation
Uses Dialogs, Unit2, Unit5, Unit6, Unit3, Unit7, Unit8, Unit1, Unit9, Unit10, DB;
Procedure ShowZapros ();
var Polya, Tabli, Svyaz, MyKey: String;
begin
if ((Tbl = 'Operation') or (Tbl = 'Station') or (Tbl = 'Ceha') or
(Tbl = 'Front') or (Tbl = 'Gruz') or (Tbl = 'Rod_vagona') or
(Tbl = 'Raion_dvizheniya') or (Tbl = 'Ves') or (Tbl = 'Vid_uslug')) then
begin
QueryString: = 'select * from' + TBL + 'order by' + pole2;
SelectQ: = DataModule2.Query1;
end;
if (Tbl = 'Vagon') then
begin
QueryString: = 'select * from Vagon V, Rod_vagona RV, Raion_dvizheniya RD where V.key_rod_vagona = RV.id and V.key_raion_dvizh = RD.id order by invent_nomer desc';
SelectQ: = DataModule2.QShow;
end;
if (Tbl = 'Operations_s_vagonom') then
begin
MyKey: = DataModule2.Qshow ['v.id'];
SelectQ: = DataModule2.QOSV;
Polya: = 'OSV .*, SNACH .*, SKON .*, FNACH .*, FKON .*, O. *, G. *';
Tabli: = 'vagon V, station SNACH, station SKON, front FNACH, front FKON, operation O, gruz G, Operations_s_vagonom OSV';
Svyaz: = 'OSV.key_station_otpr = SNACH.id and OSV.key_front_otpr = FNACH.id and OSV.key_station_naznach = SKON.id and OSV.key_front_naznach = FKON.id and OSV.key_operation = O.id and OSV.key_gruz = G. id and OSV.key_vagon = V.id and OSV.key_vagon = '+ MyKey;
QueryString: = 'select' + Polya + 'from' + Tabli + 'where' + Svyaz;
end;
if (Tbl = 'Uslugi_sv') then
begin
MyKey: = DataModule2.QOSV ['OSV.id'];
SelectQ: = DataModule2.Quslugi;
Polya: = 'USV .*, CNA .*, CS .*, ST .*, VU .*, V. *';
Tabli: = 'Ceha CNA, Ceha CS, Uslugi_sv USV, Operations_s_vagonom OSV, Stoimost ST, Vid_uslug VU, Ves V';
Svyaz: = 'USV.key_uslugi = ST.id and USV.key_na = CNA.id and USV.key_s = CS.id and USV.key_vagon = OSV.id and ST.key_vid_uslug = VU.id and ST.key_ves = V. id and USV.key_vagon = '+ MyKey;
QueryString: = 'select' + Polya + 'from' + Tabli + 'where' + Svyaz;
end;
if (Tbl = 'Stoimost') then
begin
SelectQ: = DataModule2.QSelUs;
Polya: = 'VU .*, V. *, ST .*';
Tabli: = 'Vid_uslug VU, Ves V, Stoimost ST';
Svyaz: = 'ST.key_vid_uslug = VU.id and ST.key_ves = V.id';
QueryString: = 'select' + Polya + 'from' + Tabli + 'where' + Svyaz;
end;
with SelectQ do
begin
Close;
SQL.Clear;
SQL.Add (QueryString);
Open;
end;
if (Tbl = 'Vagon') then
begin
SelectQ.Fields [0]. Visible: = false;
SelectQ.Fields [7]. Visible: = false;
SelectQ.Fields [9]. Visible: = false;
SelectQ.Fields [10]. Visible: = false;
SelectQ.Fields [12]. Visible: = false;
Form1.DBGrid1.Columns [0]. Title.Caption: = 'Місяць';
Form1.DBGrid1.Columns [1]. Title.Caption: = 'Рік';
Form1.DBGrid1.Columns [2]. Title.Caption: = '№ вагона';
Form1.DBGrid1.Columns [3]. Title.Caption: = 'Інв. № ';
Form1.DBGrid1.Columns [4]. Title.Caption: = 'виготов.';
Form1.DBGrid1.Columns [5]. Title.Caption: = 'грузопод. т. ';
Form1.DBGrid1.Columns [6]. Title.Caption: = 'Знос%';
Form1.DBGrid1.Columns [7]. Title.Caption: = 'Рід вагона';
Form1.DBGrid1.Columns [8]. Title.Caption: = 'Район руху';
end;
if (Tbl = 'Operations_s_vagonom') then
begin
SelectQ.Fields [0]. Visible: = false;
SelectQ.Fields [1]. Visible: = false;
SelectQ.Fields [2]. Visible: = false;
SelectQ.Fields [3]. Visible: = false;
SelectQ.Fields [4]. Visible: = false;
SelectQ.Fields [7]. Visible: = false;
SelectQ.Fields [8]. Visible: = false;
SelectQ.Fields [12]. Visible: = false;
SelectQ.Fields [13]. Visible: = false;
SelectQ.Fields [15]. Visible: = false;
SelectQ.Fields [17]. Visible: = false;
SelectQ.Fields [19]. Visible: = false;
SelectQ.Fields [21]. Visible: = false;
SelectQ.Fields [23]. Visible: = false;
Form6.DBGrid1.Columns [0]. Title.Caption: = 'Дата';
Form6.DBGrid1.Columns [1]. Title.Caption: = 'Час';
Form6.DBGrid1.Columns [2]. Title.Caption: = 'Вага';
Form6.DBGrid1.Columns [3]. Title.Caption: = '№ дор. вед. ';
Form6.DBGrid1.Columns [4]. Title.Caption: = '№ вед.';
Form6.DBGrid1.Columns [5]. Title.Caption: = 'Станція відпр.';
Form6.DBGrid1.Columns [6]. Title.Caption: = 'Станція підлогу.';
Form6.DBGrid1.Columns [7]. Title.Caption: = 'Фронт відпр.';
Form6.DBGrid1.Columns [8]. Title.Caption: = 'Фронт підлогу.';
Form6.DBGrid1.Columns [9]. Title.Caption: = 'Операція';
Form6.DBGrid1.Columns [10]. Title.Caption: = 'Вантаж';
end;
if (Tbl = 'Uslugi_sv') then
begin
SelectQ.Fields [0]. Visible: = false;
SelectQ.Fields [2]. Visible: = false;
SelectQ.Fields [3]. Visible: = false;
SelectQ.Fields [4]. Visible: = false;
SelectQ.Fields [5]. Visible: = false;
SelectQ.Fields [7]. Visible: = false;
SelectQ.Fields [10]. Visible: = false;
SelectQ.Fields [13]. Visible: = false;
SelectQ.Fields [14]. Visible: = false;
SelectQ.Fields [15]. Visible: = false;
SelectQ.Fields [17]. Visible: = false;
SelectQ.Fields [19]. Visible: = false;
Form7.DBGrid1.Columns [0]. Title.Caption: = 'Замовлення';
Form7.DBGrid1.Columns [1]. Title.Caption: = 'Вартість замовлення';
Form7.DBGrid1.Columns [2]. Title.Caption: = '№ цеху ісп.';
Form7.DBGrid1.Columns [3]. Title.Caption: = 'БС ц.і.';
Form7.DBGrid1.Columns [4]. Title.Caption: = '№ цеху замовлення.';
Form7.DBGrid1.Columns [5]. Title.Caption: = 'БС ц.з.';
Form7.DBGrid1.Columns [6]. Title.Caption: = 'Стоїмо. ум. ';
Form7.DBGrid1.Columns [7]. Title.Caption: = 'Вид послуги';
Form7.DBGrid1.Columns [8]. Title.Caption: = 'Одиниця виміру';
end;
if (Tbl = 'Stoimost') then
begin
SelectQ.Fields [0]. Visible: = false;
SelectQ.Fields [2]. Visible: = false;
SelectQ.Fields [4]. Visible: = false;
SelectQ.Fields [5]. Visible: = false;
SelectQ.Fields [6]. Visible: = false;
Form8.DBGrid1.Columns [0]. Title.Caption: = 'Вид послуги';
Form8.DBGrid1.Columns [1]. Title.Caption: = 'Одиниця виміру';
Form8.DBGrid1.Columns [2]. Title.Caption: = 'Вартість';
end;
if ((Tbl = 'Operation') or (Tbl = 'Station') or (Tbl = 'Ceha') or
(Tbl = 'Front') or (Tbl = 'Gruz') or (Tbl = 'Rod_vagona') or
(Tbl = 'Raion_dvizheniya') or (Tbl = 'Ves') or (Tbl = 'Vid_uslug')) then
begin
SelectQ.Fields [0]. Visible: = false;
Form3.DBGrid1.Columns [0]. Title.Caption: = Form3.Label1.Caption;
If (tbl = 'Ceha') then
begin
Form3.DBGrid1.Columns [1]. Title.Caption: = Form3.Label2.Caption;
end;
end;
end;
Procedure InsertZapros ();
var
QueryString, Polya: string;
YN: Boolean;
begin
YN: = false;
if ((Tbl = 'Operation') or (Tbl = 'Station') or (Tbl = 'Ceha') or
(Tbl = 'Front') or (Tbl = 'Gruz') or (Tbl = 'Rod_vagona') or
(Tbl = 'Raion_dvizheniya') or (Tbl = 'Ves') or (Tbl = 'Vid_uslug')) then
begin
SelectQ: = DataModule2.Query1;
with DataModule2.Query1 do
begin
First;
while (not Eof) do
begin
if (ForEdit <> SelectQ ['id']) then
begin
if DataModule2.Query1 [pole2] = ToIns then
begin
YN: = true;
Break;
end;
end;
Next;
end;
end;
if InsEdit then
begin
If (tbl = 'Ceha') then
begin
QueryString: = 'UPDATE' + TBL + 'SET' + pole2 +'='+# 39 + ToIns + # 39 +','+ pole3 +'='+# 39 + ToIns2 + # 39 + 'where' + pole1 +'='+ ForEdit ;
end
else
begin
QueryString: = 'UPDATE' + TBL + 'SET' + pole2 +'='+# 39 + ToIns + # 39 + 'where' + pole1 +'='+ ForEdit;
end;
InsEdit: = false;
end
else
begin
If (tbl = 'Ceha') then
begin
QueryString: = 'insert into' + TBL + '(' + pole2 +','+ pole3 + ') values ​​(' + # 39 + ToIns + # 39 +','+# 39 + ToIns2 + # 39 +')';
end
else
begin
QueryString: = 'insert into' + TBL + '(' + pole2 + ') values ​​(' + # 39 + ToIns + # 39 +')';
end;
end;
end;
if (Tbl = 'Stoimost') then
begin
SelectQ: = DataModule2.QSelUs;
pole1: = 'id';
pole2: = 'key_vid_uslug';
pole3: = 'key_ves';
pole4: = 'stoimost';
pole5: ='';
pole6: ='';
pole7: ='';
pole8: ='';
pole9: ='';
pole10: ='';
pole11: ='';
pole12: ='';
pole13: ='';
with SelectQ do
begin
First;
while (not Eof) do
begin
if (ForEdit <> SelectQ ['ST.id']) then
begin
if ((SelectQ [pole2] = ToIns) and (SelectQ [pole3] = ToIns2)) then
begin
YN: = true;
Break;
end;
end;
Next;
end;
end;
if InsEdit2 then
begin
QueryString: = 'UPDATE' + TBL + 'SET' + pole2 +'='+# 39 + ToIns + # 39 +','+ pole3 +'='+# 39 + ToIns2 + # 39 +','+ pole4 +'='+# 39 + ToIns3 + # 39 + 'where' + pole1 +'='+ ForEdit;
InsEdit2: = false;
end
else
QueryString: = 'insert into' + TBL + '(' + pole2 +','+ pole3 +','+ pole4 + ') values ​​(' + # 39 + ToIns + # 39 +','+# 39 + ToIns2 + # 39 + ' , '+ # 39 + ToIns3 + # 39 +')';
end;
if (Tbl = 'Vagon') then
begin
pole1: = 'id';
pole2: = 'mymonth';
pole3: = 'myyear';
pole4: = 'nomer_vagona';
pole5: = 'invent_nomer';
pole6: = 'year_izgot';
pole7: = 'gruzopodemnost';
pole8: = 'key_rod_vagona';
pole9: = 'iznos';
pole10: = 'key_raion_dvizh';
pole11: ='';
pole12: ='';
pole13: ='';
SelectQ: = DataModule2.QShow;
with SelectQ do
begin
First;
while (not Eof) do
begin
if (ForEdit <> SelectQ ['v.id']) then
begin
if (SelectQ [pole5] = ToIns4) then
begin
YN: = true;
Break;
end;
end;
Next;
end;
end;
if InsEdit3 then
begin
QueryString: = 'UPDATE' + TBL + 'SET' + pole2 +'='+# 39 + ToIns + # 39 +','+ pole3 +'='+# 39 + ToIns2 + # 39 +','+ pole4 +'='+# 39 + ToIns3 + # 39 +','+ pole5 +'='+# 39 + ToIns4 + # 39 +','+ pole6 +'='+# 39 + ToIns5 + # 39 +','+ pole7 +'='+# 39 + ToIns6 + # 39 +','+ pole8 +'='+# 39 + ToIns7 + # 39 +','+ pole9 +'='+# 39 + ToIns8 + # 39 +','+ pole10 +'='+# 39 + ToIns9 + # 39 + 'where' + pole1 +'='+ ForEdit;
InsEdit3: = false;
end
else
QueryString: = 'insert into' + TBL + '(' + pole2 + ',' + pole3 + ',' + pole4 + ',' + pole5 + ',' + pole6 + ',' + pole7 + ',' + pole8 + ',' + pole9 + ',' + pole10 + ') values ​​(' + # 39 + ToIns + # 39 + ',' + # 39 + ToIns2 + # 39 + ',' + # 39 + ToIns3 + # 39 + ',' + # 39 + ToIns4 + # 39 + ',' + # 39 + ToIns5 + # 39 + ',' + # 39 + ToIns6 + # 39 + ',' + # 39 + ToIns7 + # 39 + ',' + # 39 + ToIns8 + # 39 + ',' + # 39 + ToIns9 + # 39 +')';
end;
if (Tbl = 'Operations_s_vagonom') then
begin
SelectQ: = DataModule2.QOSV;
pole1: = 'id';
pole2: = 'key_station_otpr';
pole3: = 'key_front_otpr';
pole4: = 'key_station_naznach';
pole5: = 'key_front_naznach';
pole6: = 'mydate';
pole7: = 'mytime';
pole8: = 'key_operation';
pole9: = 'key_gruz';
pole10: = 'weight';
pole11: = 'n_dor_ved';
pole12: = 'n_ved';
pole13: = 'key_vagon';
with SelectQ do
begin
First;
while (not Eof) do
begin
if (ForEdit <> SelectQ ['OSV.id']) then
begin
if ((SelectQ [pole11] = ToIns10) and (SelectQ [pole12] = ToIns11)) then
begin
YN: = true;
Break;
end;
end;
Next;
end;
end;
if InsEdit4 then
begin
QueryString: = 'UPDATE' + TBL + 'SET' + pole2 +'='+# 39 + ToIns + # 39 +','+ pole3 +'='+# 39 + ToIns2 + # 39 +','+ pole4 +'='+# 39 + ToIns3 + # 39 +','+ pole5 +'='+# 39 + ToIns4 + # 39 +','+ pole6 +'='+# 39 + ToIns5 + # 39 +','+ pole7 +'='+# 39 + ToIns6 + # 39 +','+ pole8 +'='+# 39 + ToIns7 + # 39 +','+ pole9 +'='+# 39 + ToIns8 + # 39 +','+ pole10 +'='+# 39 + ToIns9 + # 39 +','+ pole11 +'='+# 39 + ToIns10 + # 39 +','+ pole12 +'='+# 39 + ToIns11 + # 39 +','+ pole13 +'='+# 39 + ToIns12 + # 39 + 'where' + pole1 +'='+ ForEdit;
InsEdit4: = false;
end
else
QueryString: = 'insert into' + TBL + '(' + pole2 + ',' + pole3 + ',' + pole4 + ',' + pole5 + ',' + pole6 + ',' + pole7 + ',' + pole8 + ',' + pole9 + ',' + pole10 + ',' + pole11 + ',' + pole12 + ',' + pole13 + ') values ​​(' + # 39 + ToIns + # 39 + ',' + # 39 + ToIns2 + # 39 + ',' + # 39 + ToIns3 + # 39 + ',' + # 39 + ToIns4 + # 39 + ',' + # 39 + ToIns5 + # 39 + ',' + # 39 + ToIns6 + # 39 + ',' + # 39 + ToIns7 + # 39 + ' , '+ # 39 + ToIns8 + # 39 +', '+ # 39 + ToIns9 + # 39 +', '+ # 39 + ToIns10 + # 39 +', '+ # 39 + ToIns11 + # 39 +', '+ # 39 + ToIns12 + # 39 +')';
end;
if (Tbl = 'Uslugi_sv') then
begin
SelectQ: = DataModule2.Quslugi;
pole1: = 'id';
pole2: = 'zakaz';
pole3: = 'key_vagon';
pole4: = 'key_uslugi';
pole5: = 'key_na';
pole6: = 'key_s';
pole7: = 'cena';
pole8: ='';
pole9: ='';
pole10: ='';
pole11: ='';
pole12: ='';
pole13: ='';
with SelectQ do
begin
First;
while (not Eof) do
begin
if (ForEdit <> SelectQ ['USV.id']) then
begin
if (SelectQ [pole2] = ToIns) then
begin
YN: = true;
Break;
end;
end;
Next;
end;
end;
if InsEdit5 then
begin
Polya: = pole2 +'='+# 39 + ToIns + # 39 +','+ pole3 +'='+# 39 + ToIns2 + # 39 +','+ pole4 +'='+# 39 + ToIns3 + # 39 + ',' + pole5 +'='+# 39 + ToIns4 + # 39 +','+ pole6 +'='+# 39 + ToIns5 + # 39 +','+ pole7 +'='+# 39 + ToIns6 + # 39;
QueryString: = 'UPDATE' + TBL + 'SET' + Polya + 'where' + pole1 +'='+ ForEdit;
InsEdit5: = false;
end
else
QueryString: = 'insert into' + TBL + '(' + pole2 + ',' + pole3 + ',' + pole4 + ',' + pole5 + ',' + pole6 + ',' + pole7 + ') values ​​(' + # 39 + ToIns + # 39 + ',' + # 39 + ToIns2 + # 39 + ',' + # 39 + ToIns3 + # 39 + ',' + # 39 + ToIns4 + # 39 + ',' + # 39 + ToIns5 + # 39 + ',' + # 39 + ToIns6 + # 39 +')';
end;
if (YN = false) then
begin
ShowMessage (QueryString);
with SelectQ do
begin
Close;
SQL.Clear;
SQL.Add (QueryString);
ExecSQL;
end;
end
else
ShowMessage ('Або такий запис є, або запис введена не коректно');
end;
Procedure DelZapros ();
var
TmpString: string;
begin
TmpString: = 'delete from' + TBL + 'where' + pole1 + '=' + ForDel;
/ / ShowMessage (TmpString);
with DataModule2.Query1 do
begin
Close;
SQL.Clear;
SQL.Add (TmpString);
ExecSQL;
end;
end;
Procedure SelTab ();
begin
if (Tbl = 'Rod_vagona') then
begin
Form6.Edit9.Text: = SelectQ [pole2];
Form6.Edit9.Tag: = SelectQ [pole1];
end;
if (Tbl = 'Raion_dvizheniya') then
begin
Form6.Edit10.Text: = SelectQ [pole2];
Form6.Edit10.Tag: = SelectQ [pole1];
end;
if (Tbl = 'Station') and (Form3.Caption = 'Станція відправник') then
begin
Form7.Edit1.Text: = SelectQ [pole2];
Form7.Edit1.Tag: = SelectQ [pole1];
end;
if (Tbl = 'Station') and (Form3.Caption = 'Станція одержувач') then
begin
Form7.Edit7.Text: = SelectQ [pole2];
Form7.Edit7.Tag: = SelectQ [pole1];
end;
if (Tbl = 'Front') and (Form3.Caption = 'Фронт відправник') then
begin
Form7.Edit2.Text: = SelectQ [pole2];
Form7.Edit2.Tag: = SelectQ [pole1];
end;
if (Tbl = 'Front') and (Form3.Caption = 'Фронт одержувач') then
begin
Form7.Edit8.Text: = SelectQ [pole2];
Form7.Edit8.Tag: = SelectQ [pole1];
end;
if (Tbl = 'Operation') then
begin
Form7.Edit9.Text: = SelectQ [pole2];
Form7.Edit9.Tag: = SelectQ [pole1];
end;
if (Tbl = 'Gruz') then
begin
Form7.Edit10.Text: = SelectQ [pole2];
Form7.Edit10.Tag: = SelectQ [pole1];
end;
if (Tbl = 'Ceha') and (Form3.Caption = 'Цех замовник') then
begin
Form8.Edit2.Text: = SelectQ [pole2];
Form8.Edit2.Tag: = SelectQ [pole1];
end;
if (Tbl = 'Ceha') and (Form3.Caption = 'Цех виконавець') then
begin
Form8.Edit3.Text: = SelectQ [pole2];
Form8.Edit3.Tag: = SelectQ [pole1];
end;
if (Tbl = 'Vid_uslug') then
begin
Form5.Edit1.Text: = SelectQ [pole2];
Form5.Edit1.Tag: = SelectQ [pole1];
end;
if (Tbl = 'Ves') then
begin
Form5.Edit2.Text: = SelectQ [pole2];
Form5.Edit2.Tag: = SelectQ [pole1];
end;
end;
Procedure ForReport ();
var
Polya, Tabli, Tabli2, Svyaz, Svyaz2, QueryString: string;
begin
Polya: = 'n_dor_ved, invent_nomer, OSV.mydate, OSV.mytime, STN.station as STN, FN.front as FN, CNA.n_ceha as NA, CNA.bal_schet as BSO, STK.station as STK, FK.front as FK, CS.n_ceha as CS, CS.bal_schet as CBS, G.gruz, VU.vid_uslug, VE.ves, weight, cena ';
Tabli: = 'Vagon V, Rod_vagona RV, Raion_dvizheniya RD, Operations_s_vagonom OSV, Uslugi_sv USV, Stoimost ST, Vid_uslug VU, Ves VE, Ceha CNA, Ceha CS, Station STN, Station STK';
Tabli2: = 'Front FN, Front FK, Operation OP, Gruz G';
Svyaz: = 'V.key_rod_vagona = RV.id and V.key_raion_dvizh = RD.id and V.id = OSV.key_vagon and OSV.id = USV.key_vagon and ST.id = USV.key_uslugi and VU.id = ST. key_vid_uslug and VE.id = ST.key_ves and USV.key_na = CNA.id and USV.key_s = CS.id ';
Svyaz2: = 'STN.id = OSV.key_station_otpr and STK.id = key_Station_naznach and FN.id = OSV.key_front_otpr and FK.id = OSV.key_front_naznach and OSV.key_operation = OP.id and OSV.key_gruz = G.id' ;
if ForSort then
begin
QueryString: = 'select' + Polya + 'from' + Tabli + ',' + Tabli2 + 'where' + Svyaz + 'and' + Svyaz2 + 'order by' + ForOrder;
end;
if ForFiltr then
begin
QueryString: = 'select' + Polya + 'from' + Tabli + ',' + Tabli2 + 'where' + Svyaz + 'and' + Svyaz2 + 'and' + TmpFiltr;
end;
if ((ForSort = false) and (ForFiltr = False)) then
begin
QueryString: = 'select' + Polya + 'from' + Tabli + ',' + Tabli2 + 'where' + Svyaz + 'and' + Svyaz2 + 'order by invent_nomer desc';
end;
with DataModule2.QueryRep do
begin
Close;
SQL.Clear;
SQL.Add (QueryString);
if ForFiltr then
begin
Parameters.ParamByName ('Par1'). Value: = Form10.Edit1.Text;
Parameters.ParamByName ('Par2'). Value: = Form10.Edit2.Text;
end;
Open;
end;
Form9.DBGrid1.Columns [0]. Title.Caption: = '№ дор. вед. ';
Form9.DBGrid1.Columns [1]. Title.Caption: = 'Інвент. № ';
Form9.DBGrid1.Columns [2]. Title.Caption: = 'Дата';
Form9.DBGrid1.Columns [3]. Title.Caption: = 'Час';
Form9.DBGrid1.Columns [4]. Title.Caption: = 'Станція відпр.';
Form9.DBGrid1.Columns [5]. Title.Caption: = 'Фронт відпр.';
Form9.DBGrid1.Columns [6]. Title.Caption: = '№ цеху відпр.';
Form9.DBGrid1.Columns [7]. Title.Caption: = 'БС цеху відпр.';
Form9.DBGrid1.Columns [8]. Title.Caption: = 'Станція замовлення.';
Form9.DBGrid1.Columns [9]. Title.Caption: = 'Фронт замовлення.';
Form9.DBGrid1.Columns [10]. Title.Caption: = '№ цеху замовлення.';
Form9.DBGrid1.Columns [11]. Title.Caption: = 'БС цеху замовлення.';
Form9.DBGrid1.Columns [12]. Title.Caption: = 'Вантаж';
Form9.DBGrid1.Columns [13]. Title.Caption: = 'Операція';
Form9.DBGrid1.Columns [14]. Title.Caption: = 'Од. ізм. ';
Form9.DBGrid1.Columns [15]. Title.Caption: = 'Вага';
Form9.DBGrid1.Columns [16]. Title.Caption: = 'Ціна';
end;
end.

unit Unit5;
interface
uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
Dialogs, StdCtrls, Grids, DBGrids;
type
TForm5 = class (TForm)
GroupBox1: TGroupBox;
Edit1: TEdit;
Button1: TButton;
Edit2: TEdit;
Edit3: TEdit;
Label1: TLabel;
Label2: TLabel;
Label3: TLabel;
procedure Button1Click (Sender: TObject);
procedure FormShow (Sender: TObject);
procedure Edit1Enter (Sender: TObject);
procedure Edit2Enter (Sender: TObject);
procedure FormClose (Sender: TObject; var Action: TCloseAction);
procedure Edit3Exit (Sender: TObject);
private
{Private declarations}
public
{Public declarations}
end;
var
Form5: TForm5;
implementation
Uses Unit2, Unit4, Unit3;
{$ R *. dfm}
procedure TForm5.Button1Click (Sender: TObject);
begin
ToIns: = IntToStr (Edit1.Tag);
ToIns2: = IntToStr (Edit2.Tag);
ToIns3: = Edit3.Text;
If ((Edit1.Text <>'') and (Edit2.Text <>'') and (Edit3.Text <>'')) then
begin
if EditMode4 then
begin
ForEdit: = DataModule2.QSelUs ['ST.id'];
InsEdit2: = true;
InsertZapros ();
ShowZapros ();
end
else
begin
InsertZapros ();
ShowZapros ();
ForEdit: = '-1';
end;
Form5.Close;
end
else
ShowMessage ('Всі поля обов'язкові до заповнення!');
end;
procedure TForm5.FormShow (Sender: TObject);
begin
TBL: = 'Stoimost';
if EditMode4 then
begin
Edit1.Text: = DataModule2.QSelUs ['vid_uslug'];
Edit1.Tag: = StrToInt (DataModule2.QSelUs ['key_vid_uslug']);
Edit2.Text: = DataModule2.QSelUs ['ves'];
Edit2.Tag: = StrToInt (DataModule2.QSelUs ['key_ves']);
Edit3.Text: = DataModule2.QSelUs ['stoimost'];
Form5.Edit3.SetFocus;
end
else
begin
Edit1.Text: ='';
Edit2.Text: ='';
Edit2.Tag: = 0;
Edit3.Text: ='';
Edit3.Tag: = 0;
Button1.SetFocus;
end
end;
procedure TForm5.Edit1Enter (Sender: TObject);
begin
Form3.Caption: = 'Вид послуг';
Form3.Label1.Caption: = Form3.Caption;
Tbl: = 'Vid_uslug';
pole1: = 'id';
pole2: = 'vid_uslug';
pole3: ='';
pole4: ='';
pole5: ='';
pole6: ='';
pole7: ='';
pole8: ='';
pole9: ='';
pole10: ='';
pole11: ='';
pole12: ='';
pole13: ='';
ShowZapros;
Form3.ShowModal;
Tbl: = 'Stoimost';
Form5.Edit2.SetFocus;
end;
procedure TForm5.Edit2Enter (Sender: TObject);
begin
Form3.Caption: = 'Одиниця виміру';
Form3.Label1.Caption: = Form3.Caption;
Tbl: = 'Ves';
pole1: = 'id';
pole2: = 'ves';
pole3: ='';
pole4: ='';
pole5: ='';
pole6: ='';
pole7: ='';
pole8: ='';
pole9: ='';
pole10: ='';
pole11: ='';
pole12: ='';
pole13: ='';
ShowZapros;
Form3.ShowModal;
Tbl: = 'Stoimost';
Form5.Edit3.SetFocus;
end;
procedure TForm5.FormClose (Sender: TObject; var Action: TCloseAction);
begin
if EditMode4 then
begin
EditMode4: = false;
end;
TBL: = 'Uslugi_sv';
end;
procedure TForm5.Edit3Exit (Sender: TObject);
var ResVar: real;
E: integer;
begin
try
strtofloat (Edit3.Text);
except
ShowMessage ('Тут має бути число !!... ну або поміняйте крапку на кому ;)');
Edit3.SetFocus;
end;
end;
end.
unit Unit6;
interface
uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
Dialogs, StdCtrls, Grids, DBGrids, ActnList, Menus, ComCtrls;
type
TForm6 = class (TForm)
GroupBox1: TGroupBox;
ComboBox1: TComboBox;
Edit2: TEdit;
Edit3: TEdit;
Edit5: TEdit;
Button1: TButton;
GroupBox2: TGroupBox;
DBGrid1: TDBGrid;
Label1: TLabel;
Label2: TLabel;
Label3: TLabel;
Label4: TLabel;
Label5: TLabel;
Label6: TLabel;
Label8: TLabel;
Label10: TLabel;
Edit8: TEdit;
Label12: TLabel;
Edit9: TEdit;
Edit10: TEdit;
PopupMenu1: TPopupMenu;
ActionList1: TActionList;
add: TAction;
edit: TAction;
del: TAction;
N1: TMenuItem;
N2: TMenuItem;
N3: TMenuItem;
DateTimePicker1: TDateTimePicker;
DateTimePicker2: TDateTimePicker;
procedure Button1Click (Sender: TObject);
procedure FormClose (Sender: TObject; var Action: TCloseAction);
procedure FormShow (Sender: TObject);
procedure Edit9Enter (Sender: TObject);
procedure Edit10Enter (Sender: TObject);
procedure addExecute (Sender: TObject);
procedure editExecute (Sender: TObject);
procedure delExecute (Sender: TObject);
procedure Edit2Exit (Sender: TObject);
procedure Edit3Exit (Sender: TObject);
procedure Edit5Exit (Sender: TObject);
procedure Edit8Exit (Sender: TObject);
private
{Private declarations}
public
{Public declarations}
end;
var
Form6: TForm6;
implementation
Uses Unit2, Unit4, Unit3, Unit7, DateUtils;
{$ R *. dfm}
procedure TForm6.Button1Click (Sender: TObject);
var qtmp: string;
begin
ToIns: = ComboBox1.Items [ComboBox1.ItemIndex];
ToIns2: = IntToStr (YearOf (DateTimePicker1.Date));
ToIns3: = Edit2.Text;
ToIns4: = Edit3.Text;
ToIns5: = IntToStr (YearOf (DateTimePicker2.Date));
ToIns6: = Edit5.Text;
ToIns7: = IntToStr (Edit9.Tag);
ToIns8: = Edit8.Text;
ToIns9: = IntToStr (Edit10.Tag);
If ((ComboBox1.Text <>'') and (Edit2.Text <>'') and (Edit3.Text <>'')
and (Edit5.Text <>'') and (Edit8.Text <>'') and (Edit9.Text <>'') and (Edit10.Text <>'')) then
begin
if EditMode then
begin
ForEdit: = DataModule2.QShow ['V.id'];
InsEdit3: = true;
InsertZapros ();
ShowZapros ();
end
else
begin
EditIns: = true;
InsertZapros ();
QueryString: = 'SELECT top 1 id from' + TBL + 'order by id desc';
with DataModule2.Qtmp do
begin
Close;
SQL.Clear;
SQL.Add (QueryString);
Open;
end;
qtmp: = DataModule2.Qtmp ['id'];
Form6.Close;
ShowZapros ();
DataModule2.QShow.Locate ('v.id', qtmp ,[]);
ForEdit: = '-1';
end;
Form6.Close;
end
else
ShowMessage ('Всі поля обов'язкові до заповнення!');
end;
procedure TForm6.FormClose (Sender: TObject; var Action: TCloseAction);
begin
if EditMode then
begin
EditMode: = false;
end;
end;
procedure TForm6.FormShow (Sender: TObject);
var i, k: integer;
begin
EditIns: = False;
if EditMode then
begin
DBGrid1.Visible: = true;
DateTimePicker1.Date: = StrToDate ("01 .01. '+ DataModule2.QShow [' myyear ']);
Edit2.Text: = DataModule2.QShow ['nomer_vagona'];
Edit3.Text: = DataModule2.QShow ['invent_nomer'];
DateTimePicker2.Date: = StrToDate ("01 .01. '+ DataModule2.QShow [' year_izgot ']);
Edit5.Text: = DataModule2.QShow ['gruzopodemnost'];
Edit8.Text: = DataModule2.QShow ['iznos'];
Edit9.Text: = DataModule2.QShow ['rod_vagona'];
Edit9.Tag: = DataModule2.QShow ['rv.id'];
Edit10.Text: = DataModule2.QShow ['raion_dvizh'];
Edit10.Tag: = DataModule2.QShow ['rd.id'];
For i: = 0 to ComboBox1.Items.Count do
begin
ComboBox1.ItemIndex: = i;
if ComboBox1.Items [ComboBox1.ItemIndex] = DataModule2.QShow ['mymonth'] then
k: = ComboBox1.ItemIndex;
end;
ComboBox1.ItemIndex: = k;
Tbl: = 'Operations_s_vagonom';
ShowZapros ();
end
else
begin
DateTimePicker1.Date: = Date;
DateTimePicker2.Date: = StrToDate ("01 .01.1950 ');
Edit2.Text: ='';
Edit3.Text: ='';
Edit5.Text: ='';
Edit8.Text: ='';
Edit9.Text: ='';
Edit9.Tag: = 0;
Edit10.Text: ='';
Edit10.Tag: = 0;
DBGrid1.Visible: = false;
end;
TBL: = 'Vagon';
end;
procedure TForm6.Edit9Enter (Sender: TObject);
begin
Form3.Caption: = 'Рід вагона';
Form3.Label1.Caption: = Form3.Caption;
Tbl: = 'Rod_vagona';
pole1: = 'id';
pole2: = 'Rod_vagona';
pole3: ='';
pole4: ='';
pole5: ='';
pole6: ='';
pole7: ='';
pole8: ='';
pole9: ='';
pole10: ='';
pole11: ='';
pole12: ='';
pole13: ='';
ShowZapros;
Form3.ShowModal;
Tbl: = 'Vagon';
Edit10.SetFocus;
end;
procedure TForm6.Edit10Enter (Sender: TObject);
begin
Form3.Caption: = 'Район руху';
Form3.Label1.Caption: = Form3.Caption;
Tbl: = 'Raion_dvizheniya';
pole1: = 'id';
pole2: = 'Raion_dvizh';
pole3: ='';
pole4: ='';
pole5: ='';
pole6: ='';
pole7: ='';
pole8: ='';
pole9: ='';
pole10: ='';
pole11: ='';
pole12: ='';
pole13: ='';
ShowZapros;
Form3.ShowModal;
Tbl: = 'Vagon';
Button1.SetFocus;
end;
procedure TForm6.addExecute (Sender: TObject);
begin
Form7.Caption: = 'Інформація по вагону';
Tbl: = 'Operations_s_vagonom';
pole1: = 'id';
pole2: = 'key_station_otpr';
pole3: = 'key_front_otpr';
pole4: = 'key_sttion_naznach';
pole5: = 'key_front_naznach';
pole6: = 'date';
pole7: = 'time';
pole8: = 'key_operation';
pole9: = 'key_gruz';
pole10: = 'weight';
pole11: = 'n_dor_ved';
pole12: = 'n_ved';
pole13: = 'key_vagon';
Form7.ShowModal;
if ((EditMode2 = false) and (EditIns2)) then
begin
EditMode2: = true;
Form7.ShowModal;
end;
end;
procedure TForm6.editExecute (Sender: TObject);
begin
if (DataModule2.QOSV ['OSV.id'] = Null) then
begin
ShowMessage ('Нема чого редагувати');
EditMode2: = false;
end
else
begin
EditMode2: = True;
Form7.ShowModal;
end;
end;
procedure TForm6.delExecute (Sender: TObject);
begin
if (DataModule2.QOSV ['OSV.id'] = Null) then
begin
ShowMessage ('Нема чого видаляти');
EditMode2: = false;
end
else
begin
Tbl: = 'Operations_s_vagonom';
pole1: = 'id';
pole2: = 'key_station_otpr';
pole3: = 'key_front_otpr';
pole4: = 'key_station_naznach';
pole5: = 'key_front_naznach';
pole6: = 'mydate';
pole7: = 'mytime';
pole8: = 'key_operation';
pole9: = 'key_gruz';
pole10: = 'weight';
pole11: = 'n_dor_ved';
pole12: = 'n_ved';
pole13: = 'key_vagon';
ForDel: = DataModule2.QOSV ['OSV.id'];
DelZapros;
ShowZapros ();
TBL: = 'Vagon';
end;
end;
procedure TForm6.Edit2Exit (Sender: TObject);
begin
try
strtoint (Edit2.Text);
except
ShowMessage ('Тут має бути число !!');
Edit2.SetFocus;
end;
end;
procedure TForm6.Edit3Exit (Sender: TObject);
begin
try
strtoint (Edit3.Text);
except
ShowMessage ('Тут має бути число !!');
Edit3.SetFocus;
end;
end;
procedure TForm6.Edit5Exit (Sender: TObject);
begin
try
strtoint (Edit5.Text);
except
ShowMessage ('Тут має бути число !!');
Edit5.SetFocus;
end;
end;
procedure TForm6.Edit8Exit (Sender: TObject);
begin
try
strtoint (Edit8.Text);
//---- Далі команди якщо введена річ - число
except
ShowMessage ('Тут має бути число !!');
Edit8.SetFocus;
end;
end;
end.
unit Unit7;
interface
uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
Dialogs, StdCtrls, ComCtrls, TabNotBk, Grids, DBGrids, Menus, ActnList;
type
TForm7 = class (TForm)
GroupBox1: TGroupBox;
Label2: TLabel;
Label3: TLabel;
Label4: TLabel;
Label5: TLabel;
Label6: TLabel;
Label7: TLabel;
Label8: TLabel;
Label9: TLabel;
Label10: TLabel;
Label11: TLabel;
Програмні продукти (ПП) призначені для задоволення потреб користувачів, широкого розповсюдження та продажу.
Оскільки в дипломній роботі розробляється інформаційна система обліку вагонів на під'їзній колії, що в кінцевому підсумку є програмним продуктом, розглянемо цей клас програм більш докладно.
Програмний продукт - комплекс взаємопов'язаних програм для вирішення певної проблеми (задачі) масового попиту, підготовлений до реалізації як будь-який вид промислової продукції. [1]
Відмінною особливістю програмних продуктів повинна бути їх системність - функціональна повнота і завершеність реалізованих функцій обробки, які застосовуються в сукупності.
Як правило, програмні продукти вимагають супроводу. Супровід програм масового застосування пов'язане з великими трудовитратами - виправлення виявлених помилок, створення нових версій програм і т.п.
Супровід програмного продукту - підтримка працездатності програмного продукту, перехід на його нові версії, внесення змін, виправлення виявлених помилок і т.п.
Основними характеристиками програм є:
алгоритмічна складність (логіка алгоритмів обробки інформації);
склад і глибина опрацювання реалізованих функцій обробки;
повнота та системність функцій обробки;
обсяг файлів програм;
вимоги до операційної системи та технічних засобів обробки з боку програмного засобу;
обсяг дискової пам'яті;
розмір оперативної пам'яті для запуску програм;
тип процесора;
версія операційної системи;
наявність обчислювальної мережі та ін
Показники якості програмних продуктів відображають наступні аспекти:
наскільки добре (просто, надійно, ефективно) можна використовувати програмний продукт;
наскільки легко експлуатувати програмний продукт;
чи можна використовувати програмний продукт при зміні умови його застосування та ін
Характеристики якості програмних продуктів:
Мобільність програмних продуктів означає їх незалежність від технічного комплексу системи обробки даних, операційного середовища, мережевої технології обробки даних, специфіки предметної області і т.п.
Надійність роботи програмного продукту визначається працездатністю і стійкістю в роботі програм, точністю виконання запропонованих функцій обробки, можливістю діагностики виникають у процесі роботи програм помилок.
Ефективність програмного продукту оцінюється як з позицій прямого його призначення - вимог користувача, так і з точки зору витрат обчислювальних ресурсів, необхідних для його експлуатації. Витрата обчислювальних ресурсів оцінюється через обсяг зовнішньої пам'яті для розміщення програм і об'єм оперативної пам'яті для запуску програм.
Облік людського чинника означає забезпечення дружнього інтерфейсу для роботи кінцевого користувача, наявність контекстно-залежної підказки або навчальної системи в складі програмного засобу, хорошою документації для освоєння і використання закладених у програмному засобі функціональних можливостей, аналіз і діагностику виниклих помилок і ін
Модифицируемость програмних продуктів означає здатність до внесення змін, наприклад розширення функцій обробки, перехід на іншу технічну базу обробки і т.п.
Комунікативність програмних продуктів заснована на максимально можливої ​​їх інтеграції з іншими програмами, забезпеченні обміну інформацією у спільних форматах представлення (експорт / імпорт баз даних, впровадження або зв'язування об'єктів обробки та ін.) [1]
При створенні програмного продукту високої якості всі ці аспекти повинні бути враховані і по можливості (з урахуванням пріоритетних потреб) повинні бути реалізовані при його виробництві.
Слід також зауважити, що створення програмного продукту не одномоментне дію, а робота, що займає деякий період часу і включає в себе різні етапи. Таким чином, ми приходимо до поняття життєвого циклу програмного продукту.

1.2. Життєвий цикл програмного забезпечення (ЖЦ ПЗ)

ЖЦ ПЗ - це безперервний процес, який починається з моменту прийняття рішення про необхідність його створення і закінчується в момент його повного вилучення з експлуатації.
Основним нормативним документом, що регламентує ЖЦ ПЗ, є міжнародний стандарт ISO / IEC 12207 (ISO - International Organization of Standardization - Міжнародна організація по стандартизації, IEC - International Electrotechnical Commission - Міжнародна комісія по електротехніці). Він визначає структуру ЖЦ, що містить процеси, дії і завдання, які повинні бути виконані під час створення ПЗ.
Стадія створення ПО - частина процесу створення ПЗ, обмежується часовими рамками і закінчується випуском конкретного програмного продукту. Розробка ПЗ включає наступні стадії:
1. формування вимог (аналіз)
2. проектування
3. реалізація (кодування)
4. тестування
5. впровадження
6. супровід
7. зняття з експлуатації
Стадія аналізу призначена для вивчення вимог до створюваного програмного продукту, а саме:
визначення складу та призначення функцій обробки даних програмного продукту;
встановлення вимог користувача до характеру взаємодії з програмним продуктом, типом користувальницького інтерфейсу (система меню, використання маніпулятора миша, типи підказок, види екранних документів тощо);
вимога до комплексу технічних і програмних засобів для експлуатації програмного продукту і т.д.
На даному етапі необхідно виконати формалізовану постановку задачі.
Проектування структури програмного продукту пов'язане з алгоритмізацією процесу обробки даних, деталізацією функцій обробки, розробкою структури програмного продукту (архітектури програмних модулів), структури інформаційної бази (бази даних) завдання, вибором методів і засобів створення програм - технології програмування.
Реалізація, тестування і налагодження програм є технічною реалізацією проектних рішень і виконуються за допомогою обраного інструментарію розробника (алгоритмічні мови і системи програмування, інструментальні середовища розробників і т.п.). Для великих і складних програмних комплексів, що мають розвинену модульну структуру побудови, окремі роботи даного етапу можуть виконуватися паралельно, забезпечуючи скорочення загального часу розробки програмного продукту. Важлива роль належить використовуваним при цьому інструментальним засобам програмування і відладки програм, оскільки вони впливають на трудомісткість виконання робіт, їх вартість та якість створюваних програм.
На стадії впровадження здійснюється впровадження компонентів ПЗ в експлуатацію, в тому числі конфігурування бази даних і робочих місць користувачів, забезпечення експлуатаційної документації, проведення навчання персоналу і т.д.
Експлуатація програмного продукту йде паралельно з його супроводом, при цьому експлуатація програм може починатися і в разі відсутності супроводу або продовжуватися в разі завершення супроводу ще якийсь час. У процесі експлуатації програмного продукту виробляється локалізація проблем і усунення причин їх виникнення, модифікація ПЗ в рамках встановленого регламенту, підготовка пропозицій щодо вдосконалення, розвитку та модернізації системи.
Зняття програмного продукту з продажу і відмова від супроводу відбуваються, як правило, у разі неефективності роботи програмного продукту, наявності в ньому непереборних помилок, відсутність попиту. [1]
Тривалість життєвого циклу для різних програмних продуктів неоднакова. Для більшості сучасних програмних продуктів тривалість життєвого циклу вимірюється в роках (2-3 роки). Хоча досить часто зустрічаються на комп'ютерах і давно зняті з виробництва програмні продукти.
Особливість розробки програмного продукту полягає в тому, що на початкових етапах приймаються рішення, реалізовані на подальших етапах. Допущені помилки, наприклад, при специфікації вимог до програмного продукту, призводять до величезних утрат на наступних етапах розробки або експлуатації програмного продукту і навіть до неуспеху всього проекту. Так, при необхідності внесення змін до специфікацію програмного продукту слід повторити в повному обсязі всі наступні етапи проектування та створення програмного продукту.
Кожен процес характеризується певними завданнями і методами їх вирішення, вихідними даними, отриманими на попередньому етапі, і результатами. Результатами аналізу, зокрема, є функціональні моделі, інформаційні моделі та відповідні їм діаграми. Часто ЖЦ ПО носить ітераційний характер: результати чергового етапу часто викликають зміни в проектних рішеннях, вироблених на більш ранніх етапах.

1.3. Моделі життєвого циклу ПЗ

Модель життєвого циклу відображає різні стани системи, починаючи з моменту виникнення необхідності в даній інформаційній системі і закінчуючи моментом її повного виходу з ужитку. Модель життєвого циклу - структура, що містить процеси, дії і завдання, які здійснюються в ході розробки, функціонування та супроводу програмного продукту протягом всього життя системи, від визначення вимог до завершення її використання.
В даний час відомі і використовуються наступні моделі життєвого циклу:
Каскадна модель передбачає послідовне виконання всіх етапів проекту в чітко фіксованому порядку. Перехід на наступний етап означає повне завершення робіт на попередньому етапі.
Поетапна модель з проміжним контролем. Розробка ІС ведеться итерациями з циклами зворотного зв'язку між етапами. Міжетапні коригування дозволяють враховувати реально існуюче взаємовплив результатів розробки на різних етапах; час життя кожного з етапів розтягується на весь період розробки.
Спіральна модель. На кожному витку спіралі виконується створення чергової версії продукту, уточнюються вимоги проекту, визначається його якість, і плануються роботи наступного витка. Особливу увагу приділяється початковим етапам розробки - аналізу та проектуванню, де реалізація тих чи інших технічних рішень перевіряється і обгрунтовується за допомогою створення прототипів (макетування).
На практиці найбільше поширення отримали дві основні моделі життєвого циклу:
каскадна модель (характерна для періоду 1970-1985 рр..);
спіральна модель (характерна для періоду після 1986.г.).
У ранніх проектах досить простих інформаційних систем кожен додаток являло собою єдиний, функціонально та інформаційно незалежний блок. Для розробки такого типу додатків ефективним виявився каскадний спосіб. Кожен етап завершувався після повного виконання та документального оформлення всіх передбачених робіт. [1]
Можна виділити наступні позитивні сторони застосування каскадного підходу:
на кожному етапі формується закінчений набір проектної документації, який відповідає критеріям повноти та узгодженості;
виконувані в логічній послідовності етапи робіт дозволяють планувати терміни завершення всіх робіт і відповідні витрати.
Каскадний підхід добре зарекомендував себе при побудові відносно простих інформаційних систем, коли на самому початку розробки можна досить точно і повно сформулювати всі вимоги до системи. Основним недоліком цього підходу є те, що реальний процес створення системи ніколи повністю не вкладається в таку жорстку схему, постійно виникає потреба в поверненні до попередніх етапах і уточнення або перегляд раніше прийнятих рішень. У результаті реальний процес створення інформаційної системи виявляється відповідним поетапної моделі з проміжним контролем.
Однак і ця схема не дозволяє оперативно враховувати виникаючі зміни і уточнення вимог до системи. Узгодження результатів розробки з користувачами проводиться тільки в точках, що плануються після завершення кожного етапу робіт, а загальні вимоги до інформаційної системи зафіксовані у вигляді технічного завдання на весь час її створення. Таким чином, користувачі часто отримують систему, не задовольняє їх реальним потребам.
Спіральна модель ЖЦ була запропонована для подолання перелічених проблем. На етапах аналізу і проектування реалізація технічних рішень і ступінь задоволення потреб замовника перевіряється шляхом створення прототипів. Кожен виток спіралі відповідає створенню працездатного фрагмента або версії системи. Це дозволяє уточнити вимоги, цілі і характеристики проекту, визначити якість розробки, спланувати роботи наступного витка спіралі. Таким чином, поглиблюються і послідовно конкретизуються деталі проекту, і в результаті вибирається обгрунтований варіант, який задовольняє дійсним вимогам замовника та доводиться до реалізації.
Ітеративна розробка відбиває об'єктивно існуючий спіральний цикл створення складних систем. Вона дозволяє переходити на наступний етап, не чекаючи повного завершення роботи на поточному і вирішити головне завдання - якомога швидше показати користувачам системи працездатний продукт, тим самим, активізуючи процес уточнення та доповнення вимог.
Основна проблема спірального циклу - визначення моменту переходу на наступний етап. Для її рішення вводяться тимчасові обмеження на кожен з етапів життєвого циклу, і перехід здійснюється відповідно до плану, навіть якщо не вся запланована робота закінчена. Планування виробляється на основі статистичних даних, отриманих у попередніх проектах, та особистого досвіду розробників.

1.4 Структурний підхід до проектування ПП

Проектування будь-якого програмного продукту грунтується не тільки на виборі моделі ЖЦ ПЗ і поділі робіт з його створення на стадіях проектування, а й на виборі підходу до проектування. У дипломній роботі розробка інформаційно-довідкової системи обліку вагонів велася за допомогою структурного підходу.
Сутність структурного підходу полягає в декомпозиції (розбитті) системи на автоматизує функції: система розбивається на функціональні підсистеми, які в свою чергу діляться на підфункції, що підрозділяються на завдання й так далі. Процес розбиття триває аж до конкретних процедур. При цьому автоматизована система зберігає цілісне представлення, у якому всі складові компоненти взаємопов'язані. При розробці системи "знизу-вверх" від окремих завдань до всієї системи цілісність втрачається, виникають проблеми при інформаційній стикування окремих компонентів.
Найбільш поширені методології структурного підходу базуються на ряді загальних принципів. В якості двох базових принципів використовуються наступні:
принцип "розділяй і володарюй" - принцип вирішення складних проблем шляхом їх розбиття на безліч менших незалежних задач, легких для розуміння і вирішення;
принцип ієрархічного упорядкування - принцип організації складових частин проблеми в ієрархічні деревоподібні структури з додаванням нових деталей на кожному рівні.
Виділення двох базових принципів не означає, що інші принципи є другорядними, оскільки ігнорування будь-якого з них може призвести до непередбачуваних наслідків (в тому числі і до провалу всього проекту). Основними з цих принципів є наступні:
принцип абстрагування полягає у виділенні істотних аспектів системи і відволікання від несуттєвих;
принцип формалізації полягає в необхідності суворого методичного підходу до вирішення проблеми;
принцип несуперечності полягає в обгрунтованості та узгодженості елементів;
принцип структурування даних полягає в тому, що дані повинні бути структуровані і ієрархічно організовані. [1]
Методології, технології та інструментальні засоби проектування (CASE-засоби) складають основу проекту будь-якої інформаційної системи. Методологія реалізується через конкретні технології та підтримують їх стандарти, методики та інструментальні засоби, які забезпечують виконання процесів ЖЦ.
У структурному аналізі використовуються в основному дві групи засобів, що ілюструють функції, виконувані системою і відносини між даними. Кожній групі засобів відповідають певні види моделей (діаграм), найбільш поширеними, серед яких є наступні:
SADT (Structured Analysis and Design Technique) моделі і відповідні функціональні діаграми;
DFD (Data Flow Diagrams) діаграми потоків даних;
ERD (Entity-Relationship Diagrams) діаграми "сутність-зв'язок".
Найбільш поширеним засобом моделювання даних є діаграми "сутність-зв'язок" (ERD). Даний засіб було використано в дипломній роботі для проектування спеціалізованої бази даних, на основі якої розроблялася система обліку рухомого складу на під'їзній колії. За допомогою ER-діаграм визначаються важливі для предметної області об'єкти (сутності), їх властивості (атрибути) і відношення один з одним (зв'язки). ERD безпосередньо використовуються для проектування реляційних баз даних, що відповідає обраній моделі бази даних, проектованої в даній дипломній роботі. [1]
Введемо поняття сутності, атрибута і зв'язку, оскільки на цих поняттях грунтується проектування бази даних, яка буде розглянута в наступному розділі.
Сутність - це реальний або уявний об'єкт, що має сутнісні значення для аналізованої предметної області, інформація про який підлягає зберіганню. Тип сутності характеризується незалежним існуванням і представляє безліч об'єктів реального світу з однаковими властивостями. Окремі об'єкти, які входять у цей тип, називають екземплярами об'єкту.
Атрибут - будь-яка характеристика сутності, значима для розглянутої предметної області і призначена для кваліфікації, ідентифікації, класифікації, кількісної характеристики або вираження стану сутності.
Зв'язок - пойменована асоціація між двома сутностями, значима для розглянутої предметної області. [1]

Глава 2. Основні принципи проектування бази даних

2.1 Поняття бази даних та системи управління базами даних

База даних (БД) - іменована сукупність даних, що відображає стан об'єктів та їх відносин у розглядуваній предметній області, або інакше БД - це сукупність взаємозв'язаних даних при такій мінімальної надмірності, яка допускає їх використання оптимальним чином для одного або декількох додатків в певній предметній області. [3]
У будь-якому бізнесі є дані, що в свою чергу вимагає створення деякого організованого методу чи механізму управління цими даними. Такий механізм прийнято називати системою управління базами даних (СКБД). Грунтуючись на сучасних технологіях, які довели свою користь системи управління базами даних почали розвиватися в інших напрямках, відповідаючи вимогам зростаючого бізнесу, дедалі більших обсягів корпоративних даних і, звичайно ж, технологій, пов'язаних з Internet .
Сучасна хвиля інформаційних технологій управління грунтується на використанні систем управління реляційними базами даних (СУРБД), які є розвитком традиційних СУБД. Реляційні бази даних і технології клієнт / сервер є типовою комбінацією, що дозволяє сучасним компаніям успішно обробляти дані і залишатися конкурентоспроможними в своїх секторах ринку.

2.2 Основні властивості бази даних

Для успішної реалізації системи на основі бази даних на першому місці стоїть проектування структури даних, а потім тільки здійснюється розробка додатків. Погано спроектована база даних буде поставляти некоректну інформацію, породжувати помилки, здатні призвести до прийняття неправильних рішень.
Проектована БД повинна мати певні властивості. Нижче перераховані основні властивості бази даних.
Цілісність. У кожний момент існування бази даних відомості, що містяться в ній, повинні бути несуперечливі. Цілісність БД досягається внаслідок введення обмежень цілісності, зокрема, до них належать обмеження, пов'язані з нормалізацією БД. Бажано відстежувати діапазон допустимих значень, співвідношення між значеннями в полях, особливості написання формату. Існують обмеження, що працюють тільки при видаленні записів.
Восстанавливаемость. Дана властивість передбачає можливість відновлення БД після збою системи або окремих видів псування системи. Сюди відноситься перевірка наявності файлів, складових додаток. В основному властивість відновлюваності забезпечується дублюванням БД і використанням техніки підвищеної надійності.
Безпека. Безпека БД передбачає захист даних від навмисного і ненавмисного доступу, модифікації або руйнування. Застосовується заборона несанкціонованого доступу, захист від копіювання та криптографічний захист. Також необхідні і адміністративні заходи, наприклад обмеження доступу до носіїв інформації.
Ефективність. Властивість ефективності зазвичай розуміється як:
мінімальний час реакції на запит користувача;
мінімальні потреби в пам'яті;
поєднання цих параметрів.
Граничні розміри і експлуатаційні обмеження. Граничні розміри, а також інші обмеження, що накладаються експлуатацією даної БД, можуть істотно вплинути на проектне рішення. [3]

2.3. Трирівнева архітектура бази даних
Проектування БД пов'язано з вирішенням проблем представлення даних і їх обміном між кінцевими користувачами. Вони продиктовані різними потребами і завданнями осіб, які використовують ці дані. Можна виділити чотири категорії осіб, кожна з яких має своє коло інтересів і пов'язана з певним етапом розробки та існування БД. Визначимо ці основні категорії осіб, а також їх ролі і функції на різних стадіях існування баз даних:
адміністратори даних і баз даних;
розробники баз даних;
прикладні програмісти;
кінцеві користувачі.
Дані - це важливий ресурс організації, і ними треба вміло керувати. Настільки важлива функція покладена на фахівців певного роду - Адміністраторів даних (АТ). Вони працюють з даними з самого початку процесу проектування БД і відповідають за концептуальне та логічне проектування БД, керування даними, розробку і супровід стандартів, бізнес-правил і ділових процедур.
Фізичне проектування і фізична реалізація бази даних, забезпечення безпеки і цілісності даних, забезпечення максимальної продуктивності додатків - це область дії компетенцій Адміністратора бази даних (АБД). Як видно у порівнянні з АД, обов'язки АБД більше зв'язані з вирішенням технічних проблем.
Розробники баз даних - це така група фахівців, яка функціонує під час проектування, створення і реорганізації бази даних і результатом діяльності якої є добре спроектована БД, постачальна достовірної та несуперечливої ​​інформацією всіх зацікавлених у цьому осіб.
При проектуванні великих БД всі розробники розпадаються на дві групи:
розробники логічної бази даних;
розробники фізичної бази даних.
Розробники логічної БД займаються виявленням цікавлять об'єктів і їх властивостей, зв'язків між об'єктами і тих обмежень, які необхідно накласти на записані дані. Здійснення своєї діяльності вказані розробники виконують у два етапи, які в наступних розділах будуть розглянуті докладно:
розробка концептуальної моделі БД;
розробка логічної моделі БД.
Розробники фізичної БД повинні розбиратися у функціональних можливостях обраної СУБД, знати всі варіанти можливого фізичного втілення отриманої логічної моделі даних і розуміти їх достоїнства і недоліки з тим, щоб вибрати найбільш оптимальний варіант для даного випадку і правильно вибудувати всю стратегію збереження і використання даних.
Відразу після створення БД слід приступити до розробки додатків, що надають користувачам необхідні їм функціональні можливості. Саме цю роботу виконують прикладні програмісти.
Користувачі. База даних проектується, створюється і підтримується для того, щоб обслуговувати інформаційні потреби кінцевих користувачів. Для них розробляються такі додатки, які дозволяють в максимальній мірі спростити їх ними операції.
Щоб розрізняти представлення даних кінцевими користувачами, програмістами і АБД створюються різні рівні моделей даних. Їх загальна структура представлена ​​на малюнку 2.1.
SHAPE \ * MERGEFORMAT

Б А З А ТАК Н Н И Х

Окремі користувачі БД Адміністратор БД

Фізична модель даних Опис даних, що зберігаються

Даталогіческая модель даних Опис на мові конкретної СУБД

Концептуальна модель даних Узагальнене, не прив'язане до будь-якої ЕОМ і СУБД, опис предметної області (набір даних, їх типів, зв'язків тощо)

Моделі та опису, використовувані СУБД

Предметна область (частина реального світу, яка відображається в БД)

Рис.2.1. Рівні моделей даних
Основним призначенням трирівневої архітектури є забезпечення незалежності від даних. Суть цієї незалежності полягає в тому, що зміни на нижніх рівнях ніяк не впливають на верхні рівні. [3]
Основна відмінність між зазначеними вище трьома типами моделей даних (концептуальної, логічної і фізичної) полягає у засобах представлення взаємозв'язків між об'єктами. При проектуванні БД потрібно розрізняти взаємозв'язку між об'єктами, між властивостями одного об'єкта і між властивостями різних об'єктів.

2.4. Життєвий цикл бази даних

Як і будь-який програмний продукт, база даних володіє власним життєвим циклом (ЖЦ БД). Головною складовою в життєвому циклі БД є створення єдиної бази даних і програм, необхідних для її роботи. Життєвий цикл системи бази даних визначає і життєвий цикл всієї інформаційної системи організації, оскільки база даних є фундаментальним компонентом інформаційної системи.
ЖЦ БД включає в себе такі основні етапи:
· Планування розробки бази даних;
· Визначення вимог до системи;
· Збір і аналіз вимог користувачів;
· Проектування бази даних:
· Концептуальне проектування бази даних;
· Логічне проектування бази даних;
· Фізичне проектування бази даних;
· Розробка програм;
· Реалізація;
· Завантаження даних;
· Тестування;
· Експлуатація і супровід.

2.4.1. Планування розробки бази даних

Зміст даного етапу - розробка стратегічного плану, в процесі якої здійснюється попереднє планування конкретної системи управління базами даних. Планування розробки бази даних полягає у визначенні трьох основних компонентів: обсягу робіт, ресурсів і вартості проекту. Планування розробки баз даних повинно бути пов'язано із загальною стратегією побудови інформаційної системи організації. Важливою частиною розробки стратегічного плану є перевірка здійсненності проекту, що складається з перевірки технологічної здійсненності, перевірки операційної здійсненності, перевірки економічної доцільності здійснення проекту.

2.4.2. Визначення вимог до системи

На даному етапі необхідно визначити діапазон дії програми БД, склад його користувачів і області застосування. Визначення вимог включає вибір цілей БД, з'ясування інформаційних потреб різних відділів і керівників фірми і вимог до обладнання та програмного забезпечення. При цьому також потрібно розглянути питання, чи слід створювати розподілену базу даних або ж централізовану, і які в даній ситуації знадобляться комунікаційні засоби.

2.4.3. Збір і аналіз вимог користувачів

Цей етап є попереднім етапом концептуального проектування бази даних. Проектування бази даних грунтується на інформації про ту частину організації, яка буде обслуговуватися базою даних. Інформаційні потреби з'ясовуються за допомогою анкет, опитувань менеджерів і працівників фірми, за допомогою спостережень за діяльністю підприємства, а також звітів і форм, якими фірма користується в поточний момент.

2.4.4. Проектування бази даних

Повний цикл розробки БД включає концептуальне, логічне і фізичне її проектування. Основними цілями проектування бази даних є:
· Представлення даних і зв'язків між ними, необхідних для всіх основних галузей застосування цього додатка і будь-яких існуючих груп його користувачів;
· Створення моделі даних, здатної підтримувати виконання будь-яких необхідних транзакцій обробки даних;
· Розробка попереднього варіанту проекту, структура якого дозволяє задовольнити вимоги, які пред'являються до продуктивності системи.
У створенні БД як моделі предметної області виділяють:
· Об'єктну (предметну) систему, пред'являє фрагмент реального світу;
· Інформаційну систему, що описує деяку об'єктну систему;
· Даталогіческую систему, що представляє інформаційну систему з допомогою даних.
Оптимальна модель даних повинна задовольняти таким критеріям, як структурна достовірність, простота, виразність, відсутність надмірності, розширюваність, цілісність, здатність до спільного використання.

2.4.5. Розробка додатків

Паралельно з проектуванням системи БД виконується розробка додатків. Головні складові цього процесу - це проектування транзакцій і користувальницького інтерфейсу.

2.4.6. Реалізація

На даному етапі здійснюється фізична реалізація бази даних та розроблених програм, що дозволяють користувачеві формулювати необхідні запити до БД і маніпулювати даними в БД. На цьому етапі реалізуються також використовуються додатком засоби захисту бази даних і підтримки її цілісності. Реалізація цього, а також і більш ранніх етапів проектування БД може здійснюватися за допомогою інструментів автоматизованого проектування та створення програм, які прийнято називати CASE-інструментами. Використання CASE-інструментів сприяє підвищенню продуктивності праці розробників і забезпечення ефективності самої системи, що розробляється.

2.4.7. Завантаження даних

На цьому етапі створені у відповідності зі схемою бази даних порожні файли, призначені для зберігання інформації, повинні бути заповнені даними. Наповнення бази даних може протікати по-різному, в залежності від того, чи створюється база даних знову або нова база даних призначена для заміни старої.
У першому випадку для введення інформації використовуються створені в процесі проектування БД зручні спеціальні форми, які дозволять адміністратора бази даних занести в базу заздалегідь підготовлені дані.
Якщо ж нова база даних призначена для заміни старої, то виникає проблема перенесення даних в нову систему, причому дуже часто з перетворенням формату їх подання. Дане завдання отримала назву - конвертація даних. В даний час будь-яка система управління базами даних має утиліту завантаження вже існуючих файлів в нову базу даних.

2.4.8. Тестування

Ретельне тестування повинен проходити будь-який програмний продукт тим більше такої, як прикладні програми інформаційної системи. Стратегія тестування повинна припускати використання реальних даних і повинна бути побудована таким чином, щоб весь процес виконувався суворо послідовно і методично правильно. Крім виявлення наявних в прикладних програмах і, можливо, в структурах бази даних помилок, збір статистичних даних на стадії тестування дозволяє встановити показники надійності і якості створеного програмного забезпечення.

2.4.9. Експлуатація та супровід

Даний етап є останнім, але, безумовно, і найтривалішим в життєвому циклі правильно спроектованої бази даних. Основні дії, пов'язані з цим заключним етапом, зводяться до спостереження за створеною системою, підтримці її нормального функціонування, а також до створення додаткових програмних компонентів або модернізації самої бази даних.

2.5. Моделі представлення даних

Зі зростанням популярності СУБД в 70-80-х роках з'явилося безліч різних моделей даних. У кожної з них були свої достоїнства і недоліки, які зіграли ключову роль у розвитку реляційної моделі даних, що з'явилася в чому завдяки прагненню спростити і впорядкувати перші моделі даних.
Модель даних (МД) - це деяка абстракція, у якій відбиваються найважливіші аспекти функціонування виділеної предметної області, а другорядні - ігноруються. Модель даних включає в себе набір понять для опису даних, зв'язків між ними та обмежень, накладених на дані.
Існують три основні МД та їх комбінації, на яких грунтуються сучасні БД: реляційна модель даних (РМД), мережева модель даних (СМД), ієрархічна модель даних (ІМД). [3]
Основна відмінність між цими моделями даних полягає у засобах опису взаємодій між об'єктами і атрибутами. Взаємозв'язок виражає відношення між множинами даних.
Використовують взаємозв'язку "один до одного", "один до багатьох" і "багато до багатьох". "Один до одного" - це взаємно однозначна відповідність, яке встановлюється між одним об'єктом і одним атрибутом. "Один до багатьох" - це відповідність між одним об'єктом і багатьма атрибутами. "Багато до багатьох" - це відповідність між багатьма об'єктами і багатьма атрибутами.
Розглянемо ці моделі даних більш докладно.

2.5.1. Ієрархічна модель даних

Основними інформаційними одиницями в ієрархічній моделі даних є сегмент і поле. Поле даних визначається як найменша неподільна одиниця даних, доступна користувачеві. Для сегменту визначаються тип сегмента і екземпляр сегменту. Примірник сегмента утвориться з конкретних значень полів даних. Тип сегмента - це пойменована сукупність вхідних у нього типів полів даних.
Ієрархічна модель даних базується на графових формі побудови даних. У ІМД вершині графа відповідає сегмент, а дуг - типи зв'язків предок-нащадок. В ієрархічних структурах сегмент-нащадок повинен мати в точності одного предка.

2.5.2. Мережева модель даних

Мережева модель спирається на математичну структуру, яка називається спрямованим графом. Спрямований граф складається з вузлів, з'єднаних ребрами. У контексті моделей даних вузли є об'єкти у вигляді типів записів даних, а ребра - зв'язки між об'єктами із ступенем кардинальні "один до одного" або "один до багатьох".
Основна відмінність графових форм представлення даних в мережевій структурі даних від ієрархічної структури даних полягає в тому, що нащадок в графі може мати будь-яке число предків.

2.4.3. Реляційна модель даних
Недоліки ієрархічної й мережної моделей призвели до появи нової, реляційної моделі даних, створеної Коддом в 1970 році і викликала загальний інтерес. Реляційна модель була спробою спростити структуру бази даних. У ній були відсутні явні покажчики на предків і нащадків, а всі дані були представлені у вигляді простих таблиць, розбитих на рядки і стовпці.
Саме реляційна модель є результатом більш розвинених уявлень про формування і ведення баз даних, на які накладено строгий математичний апарат. Реляційні моделі найбільш логічно і наочно відображають структуру зберігається, та внутрішніх зв'язків, що дозволяє більш повно аналізувати структуру бази даних при розробці. Це призвело до того, що саме реляційні моделі баз даних найбільш поширені в даний час і є стандартом, на який переводяться всі існуючі раніше бази даних з ієрархічної і мережевою моделлю. Ще одним вагомим доказом на користь вибору реляційної моделі є той факт, що переважна більшість коштів, що надаються для розробки баз даних орієнтовані виключно на реляційну модель. Крім того, реляційні бази даних надалі легше розширювати та інтегрувати, що є невід'ємною частиною подальшого розвитку баз даних, зі збільшенням покладених на них завдань.
Реляційної називається база даних, в якій всі дані, доступні користувачеві, організовані у вигляді таблиць, а всі операції над даними зводяться до операцій над цими таблицями. [7]
Наведене визначення не залишає місця вбудованим вказівниками, наявними в ієрархічних і мережевих СУБД. Незважаючи на це, реляційна СУБД також здатна реалізувати відносини предок / нащадок, проте ці відносини представлені виключно значеннями даних, що містяться в таблицях.
Переваги реляційної моделі можна розділити на дві групи.
Переваги для користувача:
реляційна БД являє собою набір таблиць, з якими користувач звик працювати;
не потрібно пам'ятати шляху доступу до даних і будувати алгоритми і процедури обробки свого запиту;
реляційні мови легкі для вивчення та освоєння, у той час як мови спілкування з ієрархічної й мережної моделями призначені для програмістів і мало придатні для користувачів;
Переваги обробки даних реляційної БД:
Зв'язність. Реляційне уявлення дає ясну картину взаємозв'язків атрибутів з різних відносин;
Точність. Спрямовані зв'язку в реляційної БД відсутні. Відносини за своєю природою мають більш точним змістом і піддаються маніпулюванню з використанням таких коштів, як алгебра та обчислення відносин, що забезпечують наочність і гнучкість моделі даних;
Гнучкість. Операції проекції та об'єднання дозволяють розрізати і склеювати відносини, так що програміст може отримувати різноманітні файли в потрібній формі;
Секретність. Контроль секретності спрощується. Для кожного відносини є можливість завдання правомірності доступу, засекречені показники можна виділити в окремі відносини з перевіркою прав доступу;
Простота впровадження. Фізичне розміщення однорідних (табличних) файлів набагато простіше, ніж розміщення ієрархічних і мережевих структур;
Незалежність даних. БД повинна допускати можливість розширення, тобто додавання нових атрибутів і відносин. [7]
Оскільки серед розглянутих логічних моделей даних реляційна володіє значними перевагами і малими недоліками, то вона і буде узята в основу для побудови СУБД. Розглянемо її більш докладно.

2.5.3.1 Таблиці

Таблиці - Фундаментальні об'єкти реляційної бази даних, в яких зберігається основна частина даних програми. Інформація в таблиці організується в рядки (записи) і стовпці (поля). Таблиці притаманні два компоненти: структура таблиці і дані таблиці.
Структура таблиці (також називається визначенням таблиці) специфицируется при створенні таблиці. Структура таблиці повинна бути спроектована і створена перед введенням в таблицю будь-яких даних. Вона визначає, які дані таблиця буде зберігати, а також правила, асоційовані з введенням, зміною або видаленням даних (бізнес-правила, або обмеження).
Структура таблиці включає наступну інформацію:
Ім'я таблиці - Це ім'я, за яким до таблиці можна звернутися у властивостях, методах і операторах SQL;
Стовпці таблиці - Це колонка таблиці, що містить всі дані, пов'язані з заданому поля таблиці. Кожен стовпець має ім'я і тип даного;
Табличні та столбцовие обмеження - обмеження цілісності, визначені на рівні таблиці або на рівні стовпця;
Дані таблиці - Інформація, яка збережена в таблиці. Всі дані таблиці зберігаються в рядках, кожна з яких містить порції інформації у стовпцях, визначених у структурі таблиці. Дані - та частина таблиці, до якої зазвичай повинні мати доступ користувачі програми. На перетині кожного рядка з кожним стовпцем таблиці міститься в точності одне значення даних.
Всі значення, що містяться в одному і тому ж стовпці, є даними одного типу. Безліч значень, які можуть міститися в стовпці, називається доменом цього стовпця.
У кожного стовпця в таблиці є своє ім'я, яке зазвичай служить заголовком стовпця. Всі стовпчики в одній таблиці повинні мати унікальні імена, проте дозволяється присвоювати однакові імена стовпців, розташованим в різних таблицях. Стовпці таблиці впорядковані зліва направо, і їх порядок визначається при створенні таблиці. У будь-якій таблиці завжди є як мінімум один стовпець. У стандарті ANSI / ISO не вказується максимально допустиму кількість стовпців в таблиці, проте майже у всіх комерційних СУБД ця межа існує і зазвичай становить приблизно 255 стовпців.
На відміну від стовпців, рядки таблиці не мають певного порядку. Це означає, що якщо послідовно виконати два однакових запиту для відображення вмісту таблиці, немає гарантії, що обидва рази рядки будуть перераховані в одному і тому ж порядку.
У таблиці може міститися будь-яку кількість рядків. Цілком припустимо існування таблиці з нульовою кількістю рядків. Така таблиця називається порожньою. Порожня таблиця зберігає структуру, певну її стовпцями, просто в ній не міститься дані. Стандарт ANSI / ISO не накладає обмежень на кількість рядків у таблиці, і в багатьох СУБД розмір таблиць обмежений лише вільним дисковим простором комп'ютера. В інших СУБД є максимальна межа, проте він вельми високий - близько двох мільярдів рядків, а іноді і більше.

2.5.3.2 Ключові поля

Міць реляційних баз даних полягає в тому, що з їх допомогою можна швидко знайти і зв'язати дані з різних таблиць за допомогою запитів, форм і звітів. Для цього кожна таблиця повинна містити одне або кілька полів, однозначно ідентифікують кожний запис у таблиці. Ці поля називаються ключовими полями таблиці. Ключові поля ще також називають первинним ключем. Можна виділити три типи ключових полів: лічильник, простий ключ і складовою ключ.
Оскільки рядки в реляційної таблиці не впорядковані, не можна вибрати рядок по її номеру в таблиці. У таблиці немає "першої", "останньої" або "тринадцяту" рядка.
Ключове поле можна задати таким чином, щоб при додаванні кожного запису в таблицю в це поле автоматично вносилося порядкове число, тобто організувати лічильник. Це найбільш простий спосіб створення ключових полів.
Складовою ключ застосовується у випадках, коли неможливо гарантувати унікальність значень кожного окремого поля. Найчастіше така ситуація виникає для таблиці, використовуваної для скріплення двох таблиць у відношенні "багато до багатьох".
Первинний ключ для кожного рядка таблиці є унікальним, тому в таблиці з первинним ключем немає двох абсолютно однакових рядків. Таблиця, в якій всі рядки відрізняються один від одного, в математичних термінах називається відношенням. Саме цьому терміну реляційні бази даних і зобов'язані своєю назвою, оскільки в їх основі лежать відносини.

2.5.3.3 Індекси

Індекси - Об'єкти бази даних, які забезпечують швидкий доступ до окремих рядків у таблиці. Індекс створюється з метою підвищення продуктивності операцій запитів і сортування даних таблиці. Індекси також використовуються для підтримки в таблицях деяких типів ключових обмежень; ці індекси часто створюються автоматично при визначенні обмеження.
Індекс - незалежний об'єкт, логічно окремий від таблиці; створення або видалення індексу ніяк не впливає на визначення або дані індексованої таблиці. Він зберігає високо оптимізовані версії всіх значень одного чи більше стовпців таблиці. Коли значення запитує з індексованого стовпця, процесор (ядро) бази даних використовує індекс для швидкого знаходження необхідного значення. Індекси повинні постійно підтримуватися, щоб відображати останні зміни індексованих стовпців таблиці. Процедури оновлення індексу при вставці, модифікації або видалення значення в індексований стовпець автоматично виконуються процесором бази даних. Хоча ці операції не вимагають ніяких дій з боку користувача, вони, однак, знижують ефективність деяких операцій маніпулювання даними (крім запитів на вибірку). Однак зменшення продуктивності, асоційоване з підтриманням індексу, в більшості випадків компенсується перевагами підвищення швидкодії доступу до даних, яке забезпечує індекс. Індекси забезпечують найбільші вигоди для відносно статичних таблиць, за якими часто виконуються запити.

2.5.3.4 Відносини предок / нащадок

Однією з відмінностей реляційної моделі від перших моделей представлення даних було те, що в ній були відсутні явні покажчики, використовувані для реалізації відносин предок / нащадок в ієрархічній моделі даних. Однак цілком очевидно, що відносини предок / нащадок існують і в реляційних базах даних.

2.5.3.5 Зовнішні ключі

Стовпець однієї таблиці, значення в якому збігаються зі значеннями стовпця, що є первинним ключем іншої таблиці, називається зовнішнім ключем. У сукупності первинний і зовнішній ключі створюють між таблицями, в яких вони містяться, таке ж відношення предок / нащадок, як і в ієрархічній базі даних .
Зовнішній ключ, як і первинний ключ, теж може бути комбінацією стовпців. На практиці зовнішній ключ завжди буде складовим (що складається з декількох стовпців), якщо він посилається на складовою первинний ключ в іншій таблиці. Очевидно, що кількість шпальт і їх типи даних у первинному і зовнішньому ключах збігаються.
Реляційна модель даних володіє всіма можливостями мережевої моделі за частиною вираження складних відносин.
Зовнішні ключі є невід'ємною частиною реляційної моделі, оскільки реалізують відносини між таблицями бази даних.

2.6 Проектування бази даних

2.6.1 Нормалізація як особливість проектування бази даних

Нормалізація - це процес скорочення повторень інформації в базі даних. Нормалізуються в базі даних не тільки дані, але й імена, включаючи імена об'єктів і форм. У нормалізації подвійна мета - видалити зайві копії даних і забезпечити максимальну гнучкість, як у структурах таблиць, так і в інтерфейсних додатках на випадок можливих майбутніх змін у базах даних.
Ненормалізоване база даних може містити дані, що містяться в декількох таблицях без всяких на те причин. Це може бути неприйнятним, наприклад, з точки зору безпеки, використання дискового простору, зручності оновлення бази даних і, що більш важливо, з точки зору цілісності даних. Ненормалізоване база даних - це база даних, не розділена на менші, логічно єдині і більше керовані таблиці.
Будь-яка база даних повинна плануватися з урахуванням потреб кінцевого користувача. Логічна організація бази даних, яка виконується на основі логічної моделі, є процесом реорганізації даних в логічно організовані групи легко керованих об'єктів. Логічна організація даних повинна допомогти скоротити повторення даних в базі даних, а в ідеалі взагалі позбутися від них. Використовувані в базі даних імена теж повинні бути стандартними і логічними.
Іноді процес нормалізації породжує додаткові таблиці, які були не включені в початковий проект.

2.6.1.1 Процес нормалізації

Нормальна форма - це міра глибини, до якої повинна бути виконана нормалізація бази даних. Формально існує п'ять форм, але звичайно в процесі нормалізації використовуються наступні три нормальні форми:
· Перша нормальна форма;
· Друга нормальна форма;
· Третя нормальна форма.
У цій послідовності нормальних форм кожна наступна залежить від результатів нормалізації, виконаних попередньої.
Перша нормальна форма
Метою першої нормальної форми є поділ бази даних на логічні одиниці, звані таблицями. Після того як таблиці будуть сформовані, для більшості з них будуть призначені ключові поля. Кожне з полів таблиці має бути неподільним і не повинно містити ніяких повторюваних груп.
Друга нормальна форма
Метою другої нормальної форми є виділення даних, тільки частково залежать від ключа, і приміщення цих даних в іншу таблицю. Друга нормальна форма виходить з першої нормальної форми в результаті подальшого поділу таблиць на більш дрібні таблиці.
Третя нормальна форма
Для того щоб таблиця була приведена до третьої нормальній формі, потрібно, щоб всі неключові поля повністю залежали від первинного ключа таблиці і не залежали один від одного. Таким чином, до кваліфікації другої нормальної форми додається вимога незалежності кожного неключові поля таблиці від інших неключових полів.
Угоди про присвоєння імен
Угоди про присвоєння імен виявляються виключно важливими для проведення нормалізації. Імена баз даних повинні бути інформативними і відповідати типу зберiгається в них інформації. Можуть бути встановлені і внутрішньокорпоративні угоди про імена, які можуть стосуватися не тільки імен таблиць всередині бази даних, а й імен користувачів, файлів і інших подібних об'єктів. Розробка та впровадження угод про імена має бути одним з перших кроків компанії у напрямку успішного управління базами даних. [7]

2.6.1.2 Переваги нормалізації

Нормалізація має цілий ряд переваг:
• краща загальна організація бази даних;
• скорочення числа непотрібних повторень даних;
• узгодженість даних усередині бази даних;
• більш гнучка структура бази даних;
• ефективні можливості забезпечення безпеки і надійності бази даних.
Процес нормалізації покращує організацію бази даних, полегшуючи роботу з базою даних всім, починаючи від простих користувачів до адміністратора, який відповідає за загальне управління об'єктами бази даних. Зменшується кількість повторень даних, що спрощує структуру даних і економить дисковий простір. Через скорочення дублювання даних зменшується ймовірність їх неузгодженості. Оскільки в результаті нормалізації база даних розділяється на ряд більш дрібних таблиць, модифікувати існуючі структури стає простіше. Нарешті, підвищується безпека в тому сенсі, що адміністратор бази даних отримує можливість дозволити різним користувачам доступ тільки до обмеженого переліку таблиць. Нормалізація спрощує управління безпекою.
Цілісність даних - це гарантія узгодженості та надійності даних в базі даних.
Посилальна цілісність
Посилальна цілісність просто означає залежність значень стовпця однієї таблиці від значень стовпця іншої таблиці. За допомогою вимог цілісності можна також задавати обмеження на діапазон допустимих для стовпця значень. Вимоги цілісності повинні задаватися при створенні таблиці. Посилальна цілісність забезпечується зазвичай за допомогою ключових полів і зовнішніх ключів.

2.6.1.3 Недоліки нормалізації

Хоча більшість успішно працюючих баз даних в деякій мірі нормалізовані, нормалізація має один істотний недолік: уповільнення роботи бази даних. У нормалізованої базі даних для виконання транзакцій або запитів більш інтенсивно використовується центральний процесор, потрібно більше пам'яті і більше число операцій введення-виведення, ніж у ненормалізованном. У нормалізованої базі даних потрібно знаходити відповідні таблиці і пов'язувати дані для того, щоб отримати потрібну інформацію або обробити його.

2.6.2 Концептуальне проектування бази даних

Після завершення початкових етапів ЖЦ БД, таких як: планування розробки БД, визначення вимог до системи, збір і аналіз вимог користувачів, починається процес проектування бази даних. Цей процес включає в себе повний цикл розробки бази даних і починається з концептуального проектування.
Перша фаза процесу проектування бази даних полягає у створенні аналізованої частини підприємства концептуальної (инфологической) моделі даних. Побудова її здійснюється в певному порядку: на початку створюються докладні моделі користувацьких подань даних; потім вони інтегруються в концептуальну модель даних. Концептуальне проектування призводить до створення концептуальної схеми бази даних.
Існують два основні підходи до проектування систем баз даних: "спадний" і "висхідний".
При висхідному поході, який застосовується для проектування простих баз даних з відносно невеликою кількістю атрибутів, робота починається з самого нижнього рівня - рівня атрибутів, які на основі аналізу існуючих між ними зв'язків групуються у відносини.
Проектування складних баз даних з великою кількістю атрибутів здійснюється використанням спадного підходу. Починається цей підхід з розробки моделей даних, які містять декілька високорівневих сутностей і зв'язків, потім робота триває у вигляді серії спадних уточнень низькорівневих сутностей, зв'язків та належних до них атрибутів.
Спадний підхід демонструється в концепції моделі "сутність-зв'язок". Дана модель даних належить до високорівневих моделей і базується на ряді концепцій, які використовуються для опису структури бази даних. [7]

2.6.2.1 Концептуальна модель даних

Предметна область - частина реального світу відображена в базі даних. Об'єднуючи приватні уявлення про вміст бази даних, отримані в результаті опитування користувачів, і свої уявлення про дані, які можуть знадобитися в майбутніх додатках, АБД спочатку створює узагальнене неформальний опис створюваної бази даних. Концептуальною моделлю даних називається опис, виконане з використанням природної мови, математичних формул, таблиць, графіків і інших засобів, зрозумілих всім людям, що працюють над проектуванням бази даних. [3]
Метою концептуального моделювання є забезпечення найбільш природних для людини способів збору та подання тієї інформації, яку передбачається зберігати в створюваній базі даних. Тому концептуальну модель даних намагаються будувати за аналогією з природною мовою. Основними конструктивними елементами концептуальних моделей є сутності (об'єкти), їх атрибути та зв'язки між ними. У першому розділі були наведені поняття даних елементів концептуальної моделі.
При визначенні концептуальної моделі необхідно брати до уваги наступне:
база даних повинна задовольняти актуальним інформаційним потребам організації. Отримана інформація повинна за структурою і змістом відповідати важливість справ;
база даних повинна забезпечувати одержання необхідних даних за прийнятний час, тобто відповідати заданим вимогам продуктивності;
база даних повинна задовольняти виявленим і знову виникаючим вимогам всіх користувачів;
база даних повинна легко розширюватися при реорганізації і розширенні предметної області;
база даних повинна легко змінюватися при зміні програмної та апаратної середовища.

2.6.2.2 Инфологическая модель даних "сутність-зв'язок"

Мета моделювання даних полягає в забезпеченні розробника ІС концептуальною схемою бази даних у формі однієї моделі або кількох локальних моделей, які відносно легко можуть бути відображені в будь-яку систему баз даних.
Найбільш поширеним засобом моделювання даних є діаграми "сутність-зв'язок" (ERD). З їх допомогою визначаються важливі для предметної області об'єкти (сутності), їх властивості (атрибути) і відношення один з одним (зв'язки). ER-моделі отримали широке поширення в системах CASE, що підтримують автоматизоване проектування реляційних баз даних.

2.6.3 Логічне проектування бази даних

Мета другої фази проектування бази даних полягає у створенні логічної моделі даних для досліджуваної частини підприємства. Процес проектування БД повинен спиратися на певну модель даних (реляційна, мережева, ієрархічна), яка визначається типом передбачуваної для реалізації інформаційної системи СУБД. Після чого сама концептуальна модель даних уточнюється і перетвориться в логічну модель даних. Подальше проектування бази даних в дипломній роботі буде спиратися на реляційну модель даних, тому на етапі логічного проектування розглянемо більш докладно проектування реляційної бази даних.
Створена логічна модель бази даних повинна пройти перевірку з використанням процедури послідовної нормалізації, а також повинна пройти контроль на можливість виконання всіх необхідних користувачеві транзакцій. Таким чином, дана фаза логічного проектування передбачає наступні дії:
перетворення концептуальної моделі даних у логічну модель, в результаті якого буде визначена схема реляційної моделі даних:
виняток зв'язку типу "багато до багатьох";
виняток складних зв'язків;
виняток рекурсивних зв'язків (рекурсивна зв'язок - це особливий вид зв'язку, в якій одні й ті ж екземпляри об'єкта беруть участь кілька разів у різних ролях, тому з точки зору їх реалізації належать до небажаних структурам);
виняток зв'язків з атрибутами;
виняток множинних атрибутів;
виключення надлишкових зв'язків;
перевірка моделі за допомогою концепцій нормалізації - метою застосування цієї процедури є отримання гарантій того, що кожне з відносин, отриманих на основі концептуальної моделі, знаходиться, принаймні, в третій нормальній формі;
перевірка моделі відносно транзакцій користувачів - створена реляційна модель предметної області повинна бути проаналізована в плані можливості виконання всіх транзакцій, передбачених уявленнями користувача;
· Перевірка підтримки цілісності даних:
можливість для атрибутів мати порожні значення;
обмеження для доменів атрибутів;
категоріально цілісність;
посилальна цілісність.
Побудована логічна модель даних в подальшому буде затребувана на етапі фізичного проектування, а також на етапі експлуатації та супроводу вже готової системи, дозволяючи наочно уявити будь-які вносяться до бази даних зміни. [3]
Концептуальне та логічне проектування - це ітеративні процеси, які включають в себе ряд уточнень, що продовжуються до тих пір, поки не буде отриманий найбільш відповідний структурі підприємства продукт.

2.6.4 Фізична проектування бази даних

Метою проектування на даному етапі є створення опису СУБД-орієнтованої моделі БД. Слід враховувати, що на цій стадії розробки можливі повернення на більш ранні етапи ЖЦ БД. Наприклад, рішення, прийняті на етапі фізичного проектування з метою підвищення продуктивності системи, можуть призвести до необхідності внести в структуру логічної моделі даних.
Дії, що виконуються на цьому етапі, занадто специфічні для різних моделей даних, тому їх складно узагальнити. Зупинимося на реляційної моделі даних, оскільки проектована база даних в даній дипломній роботі спирається на реляційну модель даних. У цьому випадку під фізичним проектуванням мається на увазі:
створення опису набору реляційних таблиць і обмежень для них на основі інформації, представленої в глобальній логічної моделі даних;
визначення конкретних структур зберігання даних і методів доступу до них, що забезпечують оптимальну продуктивність системи з базою даних;
розробка засобів захисту створюваної бази даних.
Фізична модель даних - модель, що визначає розміщення даних на зовнішніх носіях, методи доступу й техніку індексування. Вона також називається внутрішньою моделлю системи. [7]
Зовнішні моделі (даталогіческіе моделі) ніяк не пов'язані з типом фізичної пам'яті, в якій будуть зберігатися дані, і з методами доступу до цих даних. Внутрішні моделі (фізичні моделі) навпаки визначають і оперують розміщенням даних та їх взаємозв'язках на запам'ятовуючих пристроях.
Фізична організація даних робить основний вплив на експлуатаційні характеристики БД. Розробники СУБД намагаються створити найбільш продуктивні фізичні моделі даних, пропонуючи користувачам той чи інший інструментарій для налаштування моделі під конкретну БД.
Фізична модель даних є повністю комп'ютерно-орієнтованої і кінцеві користувачі, а часом і прикладні програмісти, не мають жодного уявлення про те, яким чином дані запам'ятовуються і витягуються або яким способом організуються індекси в таблицях для швидкого пошуку або посилальна цілісність.
Трирівнева архітектура (інфологічне, даталогіческій і фізичний рівні) дозволяє забезпечити незалежність збережених даних від використовують їх програм.

2.6.5 Етапи проектування бази даних

Етапи проектування бази даних з урахуванням розглянутих вище аспектів:
1. Проектування инфологической (концептуальної) моделі бази даних:
а) дослідження предметної області застосування та виявлення вимог кінцевих користувачів і розв'язуваних задач;
б) аналіз даних: збір основних даних (об'єкти, зв'язки між об'єктами);
в) побудова ER-діаграми бази даних.
2. Проектування даталогіческой моделі бази даних (враховувати вимоги СУБД). Збір інформації про потенційні можливості використання даних.
3. Проектування фізичної моделі бази даних:
а) створення опису набору реляційних таблиць і обмежень для них;
б) визначення конкретних структур зберігання даних і методів доступу до них, що забезпечують оптимальну продуктивність системи з базою даних;
в) розробка засобів захисту створюваної системи.
4. Реалізація бази даних (оцінка при незадовільних експлуатаційних характеристиках). [7]
За цією схемою здійснювалася реалізація бази даних для подальшого створення інформаційної системи обліку вагонів на під'їзній колії підприємства, що є кінцевою метою даної дипломної роботи.

Глава 3. Проектування користувальницького інтерфейсу
Проектування користувальницького інтерфейсу - це досить тривалий і трудомісткий процес. У процесі дизайну інтерфейсу виділяються три основні етапи, а саме: початкове проектування (часто опиняється і остаточним), створення прототипу і тестування / модифікація прототипу. Фактично процес дизайну, щоб бути успішним і безумовним, завжди прагне відбуватися за спіральної моделі в такій послідовності: проектування, потім створення прототипу, потім тестування / модифікація, потім знову тестування / модифікація і т.д. Тобто основним етапом виявляється не дизайн, а полірування вже зробленого дизайну.
Важливість початкового проектування важко переоцінити. На ньому закладаються основні концепції системи, що впливають на абсолютно всі показники якості інтерфейсу. Чим більше уваги буде приділено проектування, тим вищою буде спільну якість. Визначимо вимоги, які пред'являються до призначеного для користувача інтерфейсу, і принципи проектування користувальницького інтерфейсу.

3.1 Вимоги до інтерфейсу

Мінімізація зусиль користувача при виконанні роботи:
• скорочення тривалості операцій читання, редагування і пошуку інформації;
• зменшення часу навігації і вибору команди;
• підвищення загальної продуктивності користувача, що полягає в обсязі оброблених даних за певний період часу;
• збільшення тривалості стійкої роботи користувача і ін [1]
Стильова гнучкість:
Можливість використовувати різні інтерфейси з одним і тим же додатком, на практиці реалізується за допомогою таблиці стилів, в тому числі можливість у виборі користувачем власних установок користувальницького інтерфейсу (ПІ).
Нарощування функціональності:
Можливість розвивати програму без руйнування (тобто залишаючись у рамках) існуючого інтерфейсу.
Масштабованість:
Можливість легко налаштовувати і розширювати як інтерфейс, так і сам додаток при збільшенні числа користувачів, робочих місць, обсягу і характеристик даних.
Адаптивність до дій користувача:
Додаток повинен допускати можливість введення даних і команд безліччю різних способів (клавіатура, миша, інші пристрої) і багатоваріантність доступу до прикладних функцій (ікони, "гарячі клавіші", меню), крім того, програма повинна враховувати можливість переходу і повернення від вікна до вікна , від режиму до режиму, і правильно обробляти такі ситуації.
Незалежність в ресурсах:
Для створення користувальницького інтерфейсу повинні надаватися окремі ресурси, спрямовані на зберігання і обробку даних, необхідних для підтримки користувача (словники, контекстно-залежні списки, набори даних за умовчанням або за останнім запиту, історії запитів тощо)
Переносимість:
При переході на іншу апаратну (програмну) платформу, повинен здійснюється автоматично перенесення і користувальницького інтерфейсу, і кінцевого застосування.

3.1.1 Методи оцінки користувальницького інтерфейсу
Для оцінки необхідного рівня зручності інтерфейсу використовуються спеціальні експертні анкети, опитувальники, формуляри, check-листи.
В якості методів використовують:
• спостереження за користувачами до використання ПІ, в процесі навчання і роботи;
• відстеження мотивації користувача - думки вголос, пояснення своїх дій і намірів;
• постановка і протоколювання виконання тестових завдань.

3.1.2 Цілі та критерії оцінки користувальницького інтерфейсу

Головною метою з точки зору ергономіки (науки стосовно ефективної взаємодії людини і техніки), найважливіше в додатку - створити такий користувальницький інтерфейс, який зробить роботу ефективною і продуктивною, а також забезпечить задоволеність користувача від роботи з програмою.
Ефективність роботи означає забезпечення точності, функціональної повноти і завершеності при виконанні виробничих завдань на робочому місці користувача. Ефективність роботи відображає обсяг ресурсів, які витрачаються при виконанні завдання, як обчислювальних, так і психофізіологічних.
Створення ПІ має бути націлена на показники ефективності людино-машинної системи, які можна виміряти кількісно і об'єктивно:
· Продуктивність праці
Визначається середньою кількістю вирішених завдань, отриманими за результатами роботи групи користувачів.
· Точність роботи (кількість помилок)
Показник точності включає відсоток помилок, які зробив користувач: кількість помилок набору, варіанти помилкових шляхів або відгалужень, число неправильних звернень до даних, запитів і пр.
· Функціональна повнота
Визначається тим, якою мірою вироблений користувачем продукт (результат роботи), відповідає пред'явленим до нього вимогам; відображає ступінь використання первинних і оброблених даних, списку необхідних процедур обробки або звітів, число пропущених технологічних операцій або етапів при виконанні поставленого користувачу. Цей показник може визначатися через відсоток застосування окремих функцій у роботі.
· Завершеність роботи
Описує ступінь виконання виробничого завдання середнім користувачем за певний термін або період, частку (або довжину черги) незадоволених (необроблених) заявок, відсоток продукції, що знаходиться на проміжній стадії готовності, а також число користувачів, які виконали завдання у фіксовані терміни.
· Простота освоєння
Визначається часом освоєння інтерфейсу, виходу на продуктивний рівень.
Вимоги до зручності і комфортності інтерфейсу зростають зі збільшенням складності робіт і відповідальності користувача за кінцевий результат. Висока задоволеність від роботи досягається у разі:
• прозорою для користувача навігації та цільової орієнтації в програмі. Головне, щоб було зрозуміло, куди йдемо, і яку операцію програма після цього кроку зробить;
• ясності і чіткості розуміння користувачем текстів і значення ікон. У програмі мають бути ті слова і графічні образи, які користувач знає або зобов'язаний знати за характером його роботи або займаної посади;
• швидкості навчання при роботі з програмою, для чого необхідно використовувати переважно стандартні елементи взаємодії, їх традиційне або загальноприйняте їх розташування;
• наявності допоміжних засобів підтримки користувача (пошукових, довідкових, нормативних), в тому числі і для прийняття рішення у невизначеній ситуації (уведення за замовчуванням, обхід "зависання" процесів та ін.)
Зручний інтерфейс допомагає користувачеві впоратися з втомою і напругою при роботі в умовах високої відповідальності за результат.

3.1.3 Етапи проектування інтерфейсу

Розробка користувальницького інтерфейсу ведеться паралельно розробці програмного продукту в цілому і в основному передує його впровадження. Процес розробки ергономічного ПІ розбивається на наступні етапи:
1. Аналіз виробничої діяльності
аналіз виробничої діяльності користувача, визначення та специфікація його бізнес-функцій. Формулювання вимог до роботи користувача;
побудова користувальницької моделі даних (ERD), формування робочих місць.
2. Проектування ПІ
вибір показників оцінки користувальницького інтерфейсу;
розробка узагальненого сценарію взаємодії користувача з системою (функціональної моделі) і його попередня оцінка користувачами і Замовником (паперовий прототип ПІ);
коректування і деталізація сценарію взаємодії, вибір і доповнення стандарту (керівництва) для побудови прототипу;
розробка макетів і прототипів ПІ та їх оцінка у діловій грі, вибір остаточного варіанту.
При проектуванні користувальницького інтерфейсу наведена вище послідовність не є строго обов'язковою. Проектувальник може уявити діалог в екранних формах. [1]
Найбільш поширеною помилкою розробника є саме відсутність чіткої опрацювання виконуваних дій. Без цього подальша реалізація виявляється неузгодженою і може виявитися не відповідає кваліфікаційним вимогам, а на практиці вимогам користувача.
3. Реалізація ПІ
реалізація ПІ в коді, створення тестової версії (візуалізація);
розробка засобів підтримки користувача (словники, підказки, повідомлення, допомога тощо) та їх вбудовування в програмний код.
4. Випробування ПІ
тестування тестової версії ПІ по набору раніше визначених показників;
підготовка документації користувача та розробка програми навчання.

3.2 Принципи проектування ергономічного користувальницького інтерфейсу

Користувальницький інтерфейс додатків бази даних є одним з найважливіших компонентів системи. Інтерфейс повинен бути зручним і забезпечувати всі функціональні можливості, передбачені в специфікаціях вимог користувачів.
При проектуванні користувальницького інтерфейсу рекомендується використовувати такі основні елементи та їх характеристики:
змістовну назву;
ясні і зрозумілі інструкції;
логічно обгрунтовані групування та послідовності полів;
візуально приваблюваний вигляд вікна або поля звіту;
легко впізнавані імена полів;
узгоджену термінологію та скорочення;
узгоджене використання кольорів;
візуальне виділення простору і кордонів полів введення даних;
зручні засоби переміщення курсору;
засоби виправлення окремих помилкових символів і цілих полів;
засоби виведення повідомлень про помилки при введенні неприпустимих значень;
особливе виділення необов'язкових для введення полів;
засоби виведення пояснювальних повідомлень з описом полів;
засоби виведення повідомлення про закінчення заповнення форми.
Мета створення ергономічного інтерфейсу полягає в тому, щоб відобразити інформацію настільки ефективно наскільки це можливо для людського сприйняття і структурувати відображення на дисплеї таким чином, щоб привернути увагу до найбільш важливим одиницям інформації. Основна ж мета полягає в тому, щоб мінімізувати загальну інформацію на екрані і представити тільки те, що є необхідним для користувача.

3.2.1 Розміщення інформації на екрані

Кількість інформації, яка відображається на екрані, називається екранної щільністю. Дослідження показали, що, чим менше екранна щільність, тим відображається інформація найбільш доступна і зрозуміла для користувача і навпаки, якщо екранна щільність велика, це може викликати труднощі у засвоєнні інформації і її ясному розумінні. Проте досвідчені користувачі можуть віддавати перевагу інтерфейси з великою екранної щільністю. Повідомлення на екрані може бути згрупована і впорядкована в значимі частини. Це може бути досягнуто з використанням кадрів (фреймів), методів типу колірного кодування, рамок, негативного зображення або інших методів для залучення уваги.

3.2.2 Несуперечність і стандартизація

Дані на екрані слід розташовувати таким чином, щоб користувач знав, де знайти і де чекати виведення необхідної інформації.
інформація, на яку слід негайно звернути увагу, повинна завжди відображатися у видному місці, щоб захопити увагу користувача (наприклад, попереджувальні повідомлення та повідомлення про помилки);
інформація, яка необхідна не дуже часто (наприклад, кошти довідки) не повинна відображатися, але повинна бути доступна, коли буде потрібно;
менш термінова-менш необхідна інформація не повинна постійно перебувати перед користувачем, але повинна бути доступна, коли знадобиться;
звіти і посилання мають бути згруповані.

3.2.3 Тексти та діалоги

Деякі принципи, якими необхідно керуватися при створенні текстових діалогів і відображень:
· Текст в нижньому регістрі читається приблизно на 13% швидше, ніж текст, який надруковано повністю у верхньому регістрі;
· Символи верхнього регістру найбільш ефективні для інформації, яка повинна привернути увагу;
· Вирівняний по правому краю текст важче читати, ніж рівномірно розподілений текст з не вирівняним правим полем;
· Оптимальний інтервал між рядками дорівнює або трохи більше, ніж висота символів.

3.2.4 Засоби управління графічного інтерфейсу користувача

"Керування" - загальний термін для компонентів інтерфейсу типу слайдерів, кнопок, кадрів (фреймів), перемикачів і т.д., які служать, щоб замістити об'єкти, які є знайомими користувачам з реального світу.
Кнопки використовуються, щоб вибрати опцію або викликати подія (наприклад, запуск підпрограми).
Перемикачі подібні кнопкам вибору, в яких користувач вибирає значення з фіксованого списку, але в даному випадку, користувач може вибрати більш ніж одне значення зі списку.
Слайдери - зазвичай це елемент 'смуга прокрутки ", вони можуть бути поміщені або в горизонтальну або вертикальну лінійку на екрані.
Мітки і текстові блоки використовуються для текстової інформації. Різниця між ними - текстові поля, дозволяють користувачеві вводити текстові дані в поля, в той час як мітки - поля не редаговані, які використовуються тільки для відображення тексту, типу підказок, команд користувача і т.д.
Списки - спеціалізовані засоби управління, які відображають розкривні списки значень (часто з приєднаними слайдерами, щоб переміщатися вгору або вниз за списком) і дозволяють користувачеві вибирати значення зі списку, або вводити інше значення в приєднане текстове поле. Списки - зручний і компактний об'єкт керування, який займає мінімум місця на екрані і в той же час несе велику інформаційну навантаження. [1]

3.2.5 Меню

Необхідний елемент автоматизованої системи - меню, що дозволяє користувачеві виконувати завдання всередині програми та керувати процесом рішення. Меню - набір опцій, що відображаються на екрані, де користувачі можуть вибирати і виконувати дії, тим самим роблячи зміни в стані інтерфейсу. Гідність меню в тому, що користувачі не повинні пам'ятати назву елемента або дії, яке вони хочуть виконати - вони повинні тільки розпізнати його серед пунктів меню. Таким чином, меню може використовувати навіть недосвідчений користувач. Однак проект меню повинен бути ретельно продуманий - щоб меню було ефективним, назви пунктів меню повинні бути очевидними.
Меню може займати багато екранного місця, але є рішення для цієї проблеми - використання спливаючого або спадаючого меню. При натисканні на іконку, рядок меню або інший об'єкт викликається спливаюче або спадаюче меню.

3.2.6 Форми

Форми - основний елемент інтерфейсу. Призначення форм - зручне введення і перегляд даних, стану, повідомлень автоматизованої системи. Основні принципи проектування форм:
розміщення інформаційних одиниць на просторі форми повинно відповідати логіці її майбутнього використання: це залежить від необхідної послідовності доступу до інформаційних одиницям, частотою їх використання, а також від відносної важливості елементів;
важливо використовувати незаповнений простір, щоб створити рівновагу і симетрію серед інформаційних елементів форми, для фіксації уваги користувача в потрібному напрямку;
логічні групи елементів необхідно відокремлювати пробілами, рядками, колірними або іншими візуальними засобами;
взаємозалежні або пов'язані елементи повинні відображатися в одній формі.

3.2.7 Організація системи навігації та системи відображення станів

Навігація забезпечує користувачу здатність переміщатися між різними вікнами, інформаційними одиницями і підпрограмами в автоматизованій системі. У повноцінній системі користувач завжди може отримати інформацію про стан системи, процесу виконання або активної підпрограмі.
Існує ряд навігаційних засобів і прийомів, які допомагають користувачеві орієнтуватися в системі. Вони включають: використання заголовків сторінок для кожного екрана; використання номерів сторінок; номерів рядків і стовпців; відображення поточного імені файлу вгорі екрану.

3.2.8 Проектування повідомлень

Повідомлення можуть запропонувати користувачу:
вибрати із запропонованих альтернатив якусь опцію або набір опцій;
ввести деяку інформацію;
вибрати опцію з набору опцій, які можуть змінюватися в залежності від поточного контексту;
підтвердити фрагмент введеної інформації перед продовженням введення.
Повідомлення можуть бути поміщені в модальні діалогові вікна, які змушують користувача відповісти на питання перш, ніж може бути зроблено будь-яке інше дію. Це може бути корисно, коли система повинна змусити користувача прийняти рішення перед продовженням роботи.

3.2.9 Запобігання, виявлення та виправлення помилок

Помилки можуть бути класифіковані як:
помилки, які засновані на неправильному розумінні дії або порядку дій;
помилки, які виникли випадково, ненавмисно, наприклад помилка при введенні тексту.
Користувач завжди буде робити помилки, навіть у відмінній програмній системі, тому в системі, що розробляється завжди повинна бути передбачений захист від помилок:
примусові дії в системі, які запобігають або ускладнюють появу помилок;
забезпечення гарних та інформативних повідомлень про помилки;
використання оборотних дій, які дозволяють користувачам виправляти їх власні помилки;
забезпечення нормальної діагностики системи, в процесі якої користувачеві пояснюється, в чому суть помилки і шляхи її виправлення. [5]

Глава 4. Побудова концептуальної моделі бази даних

4.1 Дослідження предметної області застосування та виявлення вимог кінцевих користувачів і розв'язуваних завдань

При розробці бази даних передбачається здійснити рішення наступних завдань:
1. Надання загальної інформації про вагони. Це сукупність відомостей про кожному вагоні, що стоїть на під'їзній колії. Включає в себе загальну інформацію таку як: номер вагона, інвентарний номер вагона, рік виготовлення, вантажопідйомність, рід вагона, знос, район руху.
2. Надання інформації про наявні послуги.
3. Надання інформації про те, який цех є орендарем кожного вагона.
4. Надання інформації про операції з вагонами.
5. Надання інформації про вантажі, що перевозяться вагонами.
6. Надання інформації про райони руху вагонів.
7. Надання інформації про вартість послуг.
8. Ведення звітності по вагонах.

4.1.1 Визначення об'єктів бази даних і зв'язків між об'єктами

Побудова концептуальної моделі даних проводилося методом спадного проектування. Аналіз визначених вище завдань дозволяє виділити таблиці проектованої бази даних. У результаті аналізу було визначено наступні об'єкти бази даних:
1. Загальна інформація про вагони (ID, Місяць, Рік, Номер_вагона, Інвентарний_номер, Рік Виготовлення, Вантажопідйомність, Код_Род_Вагона, Знос, Код_Район_Двіженія).
Ім'я цієї таблиці в Access задане як Vagon, що дозволить без змін вставити цю назву в базу даних (назви для інших таблиць також будуть приведені англійською мовою). Ця таблиця відводиться для зберігання основних відомостей про вагони. Поле ID - унікальний числовий ідентифікатор, лічильник. Поля Місяць і Рік призначені для визначення дати появи вагона на підприємстві. Поле Номер_Вагона передбачає введення номера вагона в складі. Поле Інвентарний_номер є унікальним номером вагона. Поле Год_Ізготовленія вказує на рік виготовлення кожного вагона. Поле Вантажопідйомність є кількісною характеристикою вагона. Поле Код_Род_Вагона вказує на рід вагона, визначений у таблиці "Рід вагона". Поле Знос визначає ступінь зносу вагона у відсотках. Поле Код_Район_Двіженія вказує на район руху, визначений у таблиці "Район руху".
2. Операції з вагоном (ID, Код_Станція_отправленія, Код_Фронт_отправленія, Код_Станція_назначенія, Код_Фронт_назначенія, Дата, Час, Код_Операціі, Код_Груза, Вага, Номер_дорожной_ведомості, Номер_ведомості, Код_Вагона)
Визначимо назва цієї таблиці в Access як Operations_ s_ vagonom. Поле ID - унікальний числовий ідентифікатор, лічильник. Поля Код_Станція_отправленія і Код_Станція_назначенія вказують на станції відправлення та призначення, визначені у таблиці "Станція". Поля Код_Фронт_отправленія і Код_Фронт_назначенія вказують на фронти відправлення та прибуття, визначені у таблиці "Фронт". Поля Дата і Час визначають дату і час проведення операції над вагоном. Поле Код_Операціі вказує на операцію, визначену у таблиці "Операція". Поле Код_Груза вказує на тип вантажу, визначений у таблиці "Вантаж". Поле Вага зберігає вагу вантажу. Поля Номер_дорожной_ведомості і Номер_ведомості зберігають номери відомостей. Поле Код_Вагона вказує на вагон, визначений у таблиці "Вагон".
3. Послуги, що надаються (ID, Замовлення, Код_вагона, Код_Услугі, Код_Цеха_отправітеля, Код_Цеха_получателя, Ціна)
Назва цієї таблиці в Access - Uslugi_ sv. Поле ID - унікальний числовий ідентифікатор, лічильник. Поле Замовлення визначає номера замовлення. Поле Код_вагона вказує на номер вагона, визначений у таблиці "Вагон". Поле Код_Услугі вказує вид послуги, визначений у таблиці "Вид послуг". Поля Код_Цеха_отправітеля і Код_Цеха_получателя вказують на номери цехів, визначені у таблиці "Цехи". Поле Ціна зберігає вартість обслуговування вагона, є обчислюваним полем.
4. Вартість (ID, Код_від_услуг, Код_веса, Вартість)
Дана таблиця (Stoimost) містить інформацію про вартість послуг, що надаються. Поле ID - унікальний числовий ідентифікатор, лічильник. Поле Код_від послуг вказує на вид послуг, визначений у таблиці "Вид послуг". Поле Код_веса вказує на одиницю виміру обсягу виконуваних робіт, визначену у таблиці "Вага". Поле Вартість зберігає в собі вартість послуги, є обчислюваним полем.
5. Станції (ID, Станція)
Назва таблиці в Access задане як Station. Дана таблиця відводиться для зберігання списку станцій. ID - унікальний ідентифікатор, лічильник. Поле Станція відводиться під список станцій.
6. Фронти (ID, Фронт)
Назва таблиці в Access визначено як Front. ID - унікальний ідентифікатор, лічильник. Поле Фронт відводиться під список фронтів.
7. Рід вагона (ID, Род_вагона)
Дана таблиця (Rod_ vagona) представляє інформацію про типи вагонів. ID - унікальний ідентифікатор, лічильник. Поле Род_вагона відводиться під список типів вагонів.
8. Район руху (ID, Район_двіженія)
Таблиця Район руху (Raion_ dvizheniya) містить перелік районів, за якими рухаються вагони. ID - унікальний ідентифікатор, лічильник. Поле Район руху відводиться під список районів.
9. Операції (ID, Операция)
Таблиця Операції (Operation) містить список операцій, вироблених з вагоном. ID - унікальний ідентифікатор, лічильник. Поле Операція відводиться під перелік операцій.
10. Вантаж (ID, Вантаж)
Таблиця Вантаж (Gruz) містить список вантажів, що перевозяться вагонами. ID - унікальний ідентифікатор, лічильник. Поле Вантаж відводиться під перелік вантажів.
11. Цехи (ID, Номер_цеха, Балансовий_счет)
Таблиця Цехи (Ceha) містить список цехів, що беруть участь в операціях з вагонами. ID - унікальний ідентифікатор, лічильник. Поле Номер_цеха відводиться під список цехів. Поле Балансовий_счет зберігає номер балансового рахунку кожного цеху.
12. Вид послуг (ID, Від_услуг)
Таблиця Вид послуг (Vid_ uslug) містить список послуг, що надаються для роботи з вагоном. ID - унікальний ідентифікатор, лічильник. Поле Від_услуг відводиться під перелік послуг.
13. Вага (ID, Вага)
Таблиця Вага (Ves) призначена для зберігання одиниць вимірювання для вираховування вартості наданих послуг. ID - унікальний ідентифікатор, лічильник. Поле Вага відводиться під перелік одиниць вимірювання.

4.1.2 Инфологическая модель даних "сутність-зв'язок"

Для побудови инфологической моделі даних використовувалося CASE-засіб MS Access 2003, що дозволяє проектувати реляційні моделі даних. MS Access - є одночасно і CASE-засобом, і середовищем розробки, і дуже могутнім візуальним засобом створення звітності, ядром СУБД і середовищем виконання.
Найбільш поширеним засобом моделювання даних є діаграми "сутність-зв'язок" (ERD). З їх допомогою визначаються важливі для предметної області об'єкти (сутності), їх властивості (атрибути) і відношення один з одним (зв'язки).
Модель даних представлена ​​у вигляді схеми даних на рис.4.1.

Рис.4.1. Инфологическая модель даних "сутність-зв'язок"
Типи зв'язків, їх назву, пов'язані сутності й атрибути, за яким пов'язані сутності, представлені в таблиці 4.1.
Таблиця 4.1.

Тип зв'язку	Назва зв'язку	Зв'язок між сутностями	Атрибути
Один до багатьох	відноситься	Station, Operations_s_vagonom	Id, key_Station_otpr
Один до багатьох	відноситься	Station, Operations_s_vagonom	Id, key_Station_naznach
Один до багатьох	відноситься	Front, Operations_s_vagonom	Id, key_Front_naznach
Один до багатьох	відноситься	Front, Operations_s_vagonom	Id, key_Front_otpr
Один до багатьох	відноситься	Vagon, Operations_s_vagonom	Id, key_vagon
Один до багатьох	відноситься	Rod_vagona, Vagon	Id, key_rod_vagona
Один до багатьох	відноситься	Raion_dvizheniya, Vagon	Id, key_Raion_dvizh
Один до багатьох	відноситься	Operations_s_vagonom, Uslugi_sv	Id, key_vagon
Один до багатьох	відноситься	Operation, Operations_s_vagonom	Id, key_operation
Один до багатьох	відноситься	Gruz, Operations_s_vagonom	Id, key_Gruz
Один до багатьох	складається з	Stoimost, Uslugi_sv	Id, key_uslugi
Один до багатьох	складається з	Ceha, Uslugi_sv	Id, key_na
Один до багатьох	відноситься	Ceha, Uslugi_sv	Id, key_s
Один до багатьох	відноситься	Vid_uslug, Stoimost	Id, key_Vid_uslug
Один до багатьох	відноситься	Ves, Stoimost	Id, key_ves

4.2 Проектування логічної моделі бази даних

Як даталогіческой моделі бази даних була обрана реляційна модель, оскільки вона володіє всіма раніше перерахованими достоїнствами представлення структур даних і внутрішніх зв'язків.
Инфологическая модель бази даних легко відображається в реляційну даталогіческую модель, використовуючи описані раніше правила з перекладу.
У результаті виходить чотирнадцять таблиць реляційної бази даних, де кожна сутність безпосередньо відбивається в окрему таблицю, атрибути кожної суті стають полями цієї таблиці, а первинні ключі суті стають первинними ключами таблиці.
На даному етапі необхідно також провести нормалізацію отриманих таблиць з метою усунення надмірності даних. Ця процедура в подальшому значно полегшить зусилля, які витрачатимуться на підтримці таблиць бази даних у цілісному стані.
Якщо проаналізувати значення полів таблиці "Вагони", то видно, що деякі поля, такі як, Род_вагона, Район_двіженія приймають деякі значення з обмеженого набору, крім того, ці значення представляють собою текстові константи, які можуть бути досить великі по довжині. Аналогічними властивостями володіють поля Станція_отправленія, Станція_назначенія, Фронт_отправленія, Фронт_назначенія, Операція, Вантаж, Від_услуг, Цех_отправітель, Цех_получатель, Вага інших таблиць. Такі значення найкраще зберігати в окремій таблиці зі своїми унікальними номерами, а замість цих довгих рядків підставляти значення унікальних номерів, які призначені кожному рядку. Це дозволить скоротити дисковий простір для зберігання даних. Користувач, таким чином, може вибрати деякі значення цих полів із запропонованого в списку, що кілька прискорить процес заповнення бази даних, оскільки звільняє його від набору довгій послідовності одних і тих же рядків.
Правила нормалізації, описані раніше, наказують для таких випадків заводити окрему таблицю для кожного поля і зберігати в ній всі значення характерні тільки для одного поля. У цьому випадку таблиці бази даних будуть нормалізовані, що не накладає вимоги на процедури підтримки бази даних в цілісному стані, дає можливість "безболісних змін" у програмному коді, що може істотно скоротити час розробки в подальшому.

4.3 Проектування фізичної моделі бази даних

База даних організована в популярному форматі локальних баз даних Microsoft Access 2003. Основна мета при розробці Access 2003 полягала в спрощення побудови та застосування баз даних. Ця мета була досягнута завдяки наданню користувачам широкого кола засобів, що дозволяють легко відшукувати та застосовувати більшу частину можливостей продукту. До них можна віднести: можливість мовного введення, як для диктування, так і для сценаріїв оперативного управління; завдяки новому додатковому формату файлів Access 2003 прискорюється доступ користувачів і обробка великих баз даних; користувач має можливість багаторазово скасовувати в конструкторі дії і відновлювати результати скасованої дії при роботі з таблицями, запитами. Другий з основних цілей розробки Access 2003 було спрощення доступу до важливої ​​інформації та її аналізу, незалежно від місця розташування відповідних даних. У додатку Access 2003 розширені можливості користувача по доступу до інформації баз даних корпоративного рівня, наприклад Microsoft SQL Server.
У Access 2003 повною мірою реалізовано управління реляційними базами даних. Система підтримує первинні та зовнішні ключі і забезпечує цілісність даних, що запобігає несумісні операції оновлення або видалення даних. Завдяки розвиненій системі визначення ключових полів і індексів при створенні таблиць запити будуть виконуватися з мінімальними тимчасовими витратами. Крім того, таблиці в Access 2003 забезпечені засобами перевірки допустимості даних, що запобігають некоректний введення незалежно від того, як він здійснюється, а кожне поле таблиці має свій формат і стандартні описи, що істотно полегшує введення даних. Access 2003 підтримує всі необхідні типи полів, в тому числі, текстовий, числовий, лічильник, грошовий, дата / час, MEMO, логічний, гіперпосилання і поля об'єктів OLE. Така різноманітність типів даних може відповідати навіть самим вишуканим завданням, яким покликана служити створювана база даних. Крім того, передбачено захист на рівні користувача, що дозволяє контролювати доступ до даних окремих користувачів і цілих груп.
База даних "Облік вагонів на під'їзній колії на підприємстві" представлена ​​тринадцятий таблицями (або за термінологією реляційних баз даних - тринадцятий реляційними відносинами): Vagon, Operations_s_vagonom, Uslugi_sv, Stoimost, Station, Front, Rod_vagona, Raion_dvizheniya, Operation, Gruz , Ceha, Vid_uslug, Ves. Розглянемо структуру кожної більш докладно.
У таблиці Vagon представлена ​​загальна інформація про вагони. Поля, їх типи, і призначення представлені в таблиці 4.2.

Таблиця 4.2.

Ім'я поля	Тип поля	Призначення
Id	лічильник	Код вагона
myMonth	текстовий	Місяць
myYear	текстовий	Рік
Nomer_vagona	текстовий	Номер вагона
Invent_nomer	числовий	Інвентарний номер вагона
Year_izgot	текстовий	Рік виготовлення вагона
Gruzopodemnost	числовий	Вантажопідйомність
Key_Rod_Vagona	числовий	Код Рода вагона
Iznos	текстовий	Знос
Key_Raion_dvizh	числовий	Код Району руху

Первинним ключем таблиці є поле Id, яке однозначно визначає кожний запис у таблиці. Поле Id підтримує посилальну цілісність з таблицею Operations_ s_ vagonom за допомогою поля key_ vagon.
Деякі поля, що позначають однотипну інформацію, наприклад, поля Key_ Rod_ Vagona, Key_ Raion_ dvizh, мають цілочисельний тип, у якому закодовано певне значення. Значення цих кодів зведені в таблиці Rod_ vagona і Raion_ dvizheniya, що продиктовано міркуваннями економії пам'яті на дисковому просторі.
У таблиці Operations_ s_ vagonov представлена ​​інформація про операції, які з вагоном. Поля, їх типи, і призначення представлені в таблиці 4.3.

Таблиця 4.3.

Ім'я поля	Тип поля	Призначення
Id	лічильник	Код операції з вагоном
Key_Station_otpr	числовий	Код станції відправлення
Key_Front_otpr	числовий	Код фронту відправлення
Key_Station_naznach	числовий	Код станції призначення
Key_Front_naznach	числовий	Код фронту призначення
myDate	дата / час	Дата проведення операції
myTime	текстовий	Час проведення операції
Key_Operation	числовий	Код операції
Key_Gruz	числовий	Код вантажу
Weight	числовий	Вага
N_dor_ved	числовий	Номер дорожньої відомості
N_ved	числовий	Номер відомості
Key_Vagon	числовий	Код вагона

Первинним ключем є поле Id, однозначно визначає будь-який запис у таблиці. Поле Id підтримує посилальну цілісність з таблицею Uslugi_ sv за допомогою поля key_ vagon і показує операції і послуги для кожного вагона. Поля, що позначають однотипну інформацію, наприклад, поля Key_Station_otpr, Key_Front_otpr, Key_Station_naznach, Key_Front_naznach, Key_Operation, Key_Gruz, Key_Vagon. Мають цілочисельний тип, у якому закодовано певне значення. Значення цих кодів зведені в таблиці Station, Front, Operation, Gruz і Vagon, що продиктовано міркуваннями економії пам'яті на дисковому просторі. Поля myDate, myTime, N_dor_ved, N_ved були введені для обліку часу занесення інформації в БД.
Таблиця Uslugi_ sv являє собою список надаваних послуг з їх кінцевою вартістю. Поля, їх типи, і призначення представлені в таблиці 4.4.

Таблиця 4.4.

Ім'я поля	Тип поля	Призначення
Id	числовий	Код послуги з вартістю
Zakaz	текстовий	Номер замовлення
Key_vagon	числовий	Код вагона
Key_uslugi	числовий	Код послуги
Key_na	числовий	Код цеху одержувача
Key_s	числовий	Код цеху оправітеля
cena	грошовий	Вартість послуги

Первинним ключем є поле Id, однозначно визначає будь-який запис у таблиці. Поля Key_ vagon, Key_ uslugi, Key_ na, Key_ s мають цілочисельний тип, у якому закодовано певне значення. Значення цих кодів зведені в таблиці Vagon, Stoimost, Ceha, що продиктовано міркуваннями економії пам'яті на дисковому просторі. Поле Cena є обчислюваним полем.
У таблиці Stoimost представлена ​​інформація про вартість надання послуги за одиницю виміру. Поля, їх типи, і призначення представлені в таблиці 4.5.
Таблиця 4.5.

Ім'я поля	Тип поля	Призначення
Id	лічильник	Код вартості
Key_Vid_uslug	текстовий	Код виду послуги
Key_ves	числовий	Код одиниці виміру
Stoimost	грошовий	Вартість за одиницю виміру

Первинним ключем є поле Id. Поле key_ uslugi підтримує посилальну цілісність з таблицею Uslugi_ sv і зберігає код послуги. Поля Key_ Vid_ uslug і Key_ ves мають цілочисельний тип, у якому закодовано певне значення. Значення цих кодів зведені в таблиці Vid_ uslug і Ves, що продиктовано міркуваннями економії пам'яті на дисковому просторі. Поле Stoimost є обчислюваним полем.
У таблиці Station являє собою список станцій, за якими рухаються вагони. Поля, їх типи, і призначення представлені в таблиці 4.6.
Таблиця 4.6.

Ім'я поля	Тип поля	Призначення
Id	лічильник	Код станції
Station	текстовий	Назва станції

Первинним ключем є поле Id. Поля key_ station_ otpr і key_ station_ naznach підтримують посилальну цілісність з таблицею Operations_ s_ vagonom.
У таблиці Front представлений список фронтів прибуття і відправлення. Поля, їх типи, і призначення представлені в таблиці 4.7.
Таблиця 4.7.

Ім'я поля	Тип поля	Призначення
Id	лічильник	Код фронту
Front	текстовий	Фронт

Первинним ключем є поле Id. Поля key_ front_ otpr і key_ front_ naznach підтримують посилальну цілісність з таблицею Operations_ s_ vagonom. У таблиці Rod vagona представлений список пологів вагонів. Поля, їх типи, і призначення представлені в таблиці 4.8.
Таблиця 4.8.

Ім'я поля	Тип поля	Призначення
Id	лічильник	Код роду вагона
Rod_vagona	текстовий	Рід вагона

Первинним ключем є поле Id. Поле key_ Rod_ vagona підтримує посилальну цілісність з таблицею Vagon.
У таблиці Raion_ dvizheniya представлений список районів руху вагонів. Поля, їх типи, і призначення представлені в таблиці 4.9.
Таблиця 4.9.

Ім'я поля	Тип поля	Призначення
Id	лічильник	Код району руху
Raion_dvizh	текстовий	Район руху

Первинним ключем є поле Id. Поле key_ Raion_ dvizh підтримує посилальну цілісність з таблицею Vagon. У таблиці Operation представлений список надаваних операцій. Поля, їх типи, і призначення представлені в таблиці 4.10.
Таблиця 4.10.

Ім'я поля	Тип поля	Призначення
Id	лічильник	Код операції
Operation	текстовий	Найменування операції

Первинним ключем є поле Id. Поле key_ Operation підтримує посилальну цілісність з таблицею Operations_s_vagonom. У таблиці Gruz представлений список вантажів, що перевозяться вагонами. Поля, їх типи, і призначення представлені в таблиці 4.11.
Таблиця 4.11.

Ім'я поля	Тип поля	Призначення
Id	лічильник	Код вантажу
Gruz	текстовий	Найменування вантажу

Первинним ключем є поле Id. Поле key_ Gruz підтримує посилальну цілісність з таблицею Operations_s_vagonom. У таблиці Ceha представлений список цехів, що беруть участь в операціях з вагонами. Поля, їх типи, і призначення представлені в таблиці 4.12.

Таблиця 4.12.

Ім'я поля	Тип поля	Призначення
Id	лічильник	Код цеху
N_ceha	текстовий	Номер цеху
Bal_schet	числовий	Балансовий рахунок цеху

Первинним ключем є поле Id. Поля key_ na і key_ s підтримують посилальну цілісність з таблицею Uslugi_ sv. У таблиці Vid uslug представлений список послуг, що надаються для роботи з вагонами. Поля, їх типи, і призначення представлені в таблиці 4.13.
Таблиця 4.13.

Ім'я поля	Тип поля	Призначення
Id	лічильник	Код послуги
Vid_uslug	текстовий	Вид послуги

Первинним ключем є поле Id. Поле key_ Vid_ uslug підтримує посилальну цілісність з таблицею Stoimost.
У таблиці Ves представлений список одиниць вимірювання для вичілсенія вартості послуг. Поля, їх типи, і призначення представлені в таблиці 4.14.
Таблиця 4.14.

Ім'я поля	Тип поля	Призначення
Id	лічильник	Код одиниці виміру
Ves	текстовий	Одиниця виміру

Первинним ключем є поле Id. Поле key_ ves підтримує посилальну цілісність з таблицею Stoimost. Такий спосіб представлення даних є найбільш зручним, оскільки дозволяє легко зберігати цілісність бази даних, тому що дані знаходяться в одному місці, і при зміні значення немає необхідності змінювати значення в усіх записах таблиці, що використовують це значення.

Глава 5. Реалізація проекту

5.1 Набір компонентів, що використовуються для створення додатків

Створена структура, схема якої наведена в Microsoft Access (мал. 5.1.), Стала основою для розробки програми, що надасть користувачам необхідні їм функціональні можливості.

Рис. 5.1. Схема даних
Всі описані таблиці, що становлять основу бази даних, функціонують у рамках створеної системи управління базою даних з обліку вагонів на під'їзній колії. СУБД з обліку вагонів на під'їзній колії створена засобами середовища програмування Delphi 7.0 і реалізує всі необхідні вимоги, які висувалися в постановці завдання, і виконує повний спектр завдань, з якими стикаються працівники підприємства з обліку комп'ютерного обладнання.

5.2 Робота з режимами програми Diplom

У даній дипломній роботі описується інформаційно-довідкова система з обліку перебування вагонів на під'їзній колії. Для того щоб почати роботу з програмою необхідно включити системний блок та монітор ПК. Для роботи програми необхідна наявність операційної системи Windows 98 або вище. Після завантаження ПК слід скопіювати програму на жорсткий диск. Для цього слід встановити носій з програмою в привід, а потім:
якщо ви знаходитесь в операційній системі типу DOS в командному рядку, вам необхідно вказати шлях до приводу, в якому перебуває носій з програмою, наприклад: "а: \". Потім провести копіювання з носія в заздалегідь створений вами каталог на жорсткому диску;
якщо ви знаходитесь в операційній системі Windows вам слід двічі клацнути лівою кнопкою мишки по іконці "Мій комп'ютер", потім двічі клацнути на іконці приводу, в якому встановлений носій з програмою, наприклад: "Диск 3,5 (А)". Потім слід виділити і скопіювати всі файли з носія в створену вами папку на жорсткому диску.
Процедура копіювання виконується один раз після придбання даної програми.
Після процедури копіювання вам слід зайти в папку, в яку ви скопіювали програму, і клацнути двічі ліву кнопку мишки на файлі diplom.exe для запуску програми. На екрані з'явиться основна форма програми (рисунок 5.2).

Малюнок 5.2

На головній формі відображається інформація про всіх вагонах на під'їзних шляхах (місяць, рік, номер вагона, інвентарний номер вагона, рік виготовлення, знос, рід вагона, район руху). При першому запуску програми список вагонів порожній.
Меню головної форми: "Файл" і "Допомога".
При відкритті меню "Файл" можна побачити підменю "Вихід" і підменю "Друк звітів" (рисунок 5.3). Підменю "вихід" призначено для виходу з програми, так само для виходу можна використовувати хрестик (х), що розташовується на вікні у правому верхньому кутку.

Малюнок 5.3
Підменю "Друк звітів" відкриває форму звітів (рисунок 5.4)

Малюнок 5.4
У цій формі представлена ​​вся інформація, необхідна для звітності по вагонах. Форма містить меню "Сортування", "Фільтрація", "Повна", "Друк".
При натисканні клавішею миші на меню "Сортування" з'явиться форма "Сортування" (рисунок 5.5).

Малюнок 5.5
У цій формі можна відсортувати інформацію в звіті за обраним одному або декільком вибраним критеріям. Для цього слід вибрати спочатку тип сортування (за зростанням або за спаданням), потім вибрати критерій сортування. Якщо сортування проводиться за одним критерієм, то після його вибору слід натиснути мишею кнопку "Close". Якщо сортування буде проводитися за кількома критеріями, то після вибору кожного з них слід натискати кнопку "Next", після закінчення вибору слід натиснути кнопку "Close".
При відкритті меню "Фільтрація", з'являється підменю "У діапазоні" і "Поза діапазону". Залежно від обраного критерію фільтрації, буде відібрана інформація, що належить зазначеному діапазону (у діапазоні) або не належить діапазону (поза діапазону). При натисканні на будь-яке з підменю з'являється форма "Фільтрація" (малюнок 5.6).

Малюнок 5.6
Інформацію можна відфільтрувати або по одному полю, або декільком. Управління проводиться аналогічно управлінню формою "Сортування". Діапазон вказується в нижніх полях.
Меню "Повна" дозволяє відобразити всі наявні в БД вагони та інформацію про них.
Меню "Друк" відкриває форму звіту (рисунок 5.7).

Малюнок 5.7
У формі можна побачити інформацію, яка буде виведена на друк. Для виводу на друк слід клікнути мишею значок принтера.
Меню "Допомога" містить підменю "Довідка" і "Про програму" (рисунок 5.8)


Малюнок 5.8
При вході в підменю "Про програму" з'являється вікно з довідкою про програму (в даному випадку прізвище розробника) (рисунок 5.9). При вході в меню "Довідка" відкривається вікно допомоги по роботі з програмою (малюнок 5.10).

Малюнок 5.9

Малюнок 5.10
У головній формі (рисунок 5.1) при натисканні правої кнопки миші на поле у ​​списку вагонів, з'являється спливаюче меню, яке складається з наступних пунктів: "Додати", "Видалити" і "Редагувати".
При натисканні пункту "Додати" з'являється діалогове вікно для введення даних (малюнок 5.11). Вводяться даними є: місяць і рік занесення даних, номер вагона, інвентарний номер вагона, рік виготовлення, вантажопідйомність, літер, приналежність, знос (%), рід вагона, район руху.

Малюнок 5.11
Поля Номер, Інвентарний номер, Вантажопідйомність є числовими, а тому вводити можна лише числа. В іншому випадку з'являється діалогове вікно (рисунок 5.12), в якому слід натиснути "ОК" і правильно ввести дані.

Малюнок 5.12
При приміщенні курсору в полі Рід вагона, з'являється діалогове вікно (рисунок 5.13), в якому можна вибрати необхідний рід вагона.

Малюнок 5.13
Поля в цьому діалоговому вікні можна додавати і видаляти. Для додавання даних необхідно в полі Рід вагона ввести найменування, після чого натиснути "Оk" і дані будуть додані до списку. Для видалення слід правою кнопкою миші клацнути на рядку, яку слід видалити і в меню натиснути "Видалити" лівою кнопкою миші. Для вибору даних із списку слід лівою кнопкою миші клацнути на потрібному рядку. Після цієї відкриється діалогове вікно (рисунок 5.14) "Район руху".

Малюнок 5.14

Це діалогове вікно також можна викликати, помістивши курсор у поле "Район руху" в діалоговому вікні "Інформація по вагону".
Поля в діалоговому вікні "Район руху" можна додавати і видаляти. Для додавання даних необхідно в полі Район руху ввести найменування, після чого натиснути "Оk" і дані будуть додані до списку. Для видалення слід правою кнопкою миші клацнути на рядку, яку слід видалити і в меню натиснути "Видалити" лівою кнопкою миші. Для вибору даних із списку слід лівою кнопкою миші клацнути на потрібному рядку.
Після заповнення всіх полів слід натиснути кнопку "ОК". Якщо заповнені були не всі поля, то з'явиться повідомлення (рисунок 5.15):

Малюнок 5.15
У повідомленні необхідно натиснути кнопку "Оk" лівою клавішею миші і заповнити всі поля в діалоговому вікні. Після чого знову натиснути "Оk". Якщо такий запис вже є, то з'явиться повідомлення про це (малюнок 5.16):

Малюнок 5.16
У повідомленні необхідно натиснути "Оk" лівою клавішею миші і перевірити введену інформацію і натиснути кнопку "Оk" в діалоговому вікні "Інформація по вагону".
Якщо все було введено вірно, то нижня частина діалогового вікна стане активною (малюнок 5.16)

Малюнок 5.16
Нижня частина названа "Операції з вагоном". Тут знаходиться список операцій, проведених з вагоном. Спочатку список порожній. Для його заповнення потрібно на полі даних натиснути правою кнопкою миші і вибрати з меню, що "Додати". Відкриється діалогове вікно "Інформація по вагону" (малюнок 5.17), де потрібно внести дані: Номер відомості, Номер дорожньої відомості, Дата проведення операції, Час проведення операції, Станція відправник, Фронт відправлення, Станція одержувач, Фронт отримання, Операція, Вантаж, Вага вантажу.

Малюнок 5.17
Поля Номер відомості, Номер дорожньої відомості, Вага вантажу є числовими. Тому в разі введення літер або символів з'явиться повідомлення (малюнок 5.18):

Малюнок 5.18
У вікні необхідно натиснути "Оk" і виправити невірно введені дані.
Дані для заповнення полів Станція відправник, Станція одержувач беруться із списків (малюнок 5.19).

Малюнок 5.19
Для вибору станції потрібно клацнути два рази лівою клавішею мишки на потрібній станції. Для того щоб додати до списку станцію потрібно ввести в поле Станція відправник / одержувач назва станції і натиснути "Оk", після чого нова станція з'явиться у списку. Для того щоб видалити зі списку станцію, необхідно клацнути правою кнопкою миші на назві станції в поле даних і в меню вибрати "Видалити". Станція буде видалена.
Дані для заповнення полів Фронт відправлення, Фронт отримання беруться із списків (малюнок 5.20).

Малюнок 5.20
Для вибору фронту потрібно клацнути два рази лівою клавішею мишки на потрібному фронті. Для того щоб додати до списку фронт потрібно ввести в поле Фронт відправник / одержувач назва станції і натиснути "Оk", після чого новий фронт з'явиться в списку. Для того щоб видалити зі списку фронт, необхідно клацнути правою кнопкою миші на назві фронту в полі даних і в меню вибрати "Видалити". Фронт буде видалено.
Дані для заповнення поля Операція беруться зі списку (малюнок 5.21).

Малюнок 5.21
Для вибору операції потрібно клацнути два рази лівою клавішею мишки на потрібній операції. Для того щоб додати до списку операцію потрібно ввести в поле Операція назву операції і натиснути "Оk", після чого нова операція з'явиться в списку. Для того щоб видалити зі списку операцію, необхідно клацнути правою кнопкою миші на назві операції в полі даних і в меню вибрати "Видалити". Операція буде видалена.
Дані для заповнення поля Вантаж беруться зі списку (малюнок 5.22).

Малюнок 5.22
Для вибору вантажу потрібно клацнути два рази лівою клавішею мишки на потрібному вантаж. Для того щоб додати до списку вантаж потрібно ввести в поле Вантаж назву вантажу і натиснути "Оk", після чого новий вантаж з'явиться в списку. Для того щоб видалити зі списку вантаж, необхідно клацнути правою кнопкою миші на назві вантажу в поле даних і в меню вибрати "Видалити". Вантаж буде видалено.
Після введення всіх даних необхідно натиснути кнопку "Оk" в діалоговому вікні "Інформація по вагону".
Якщо все було введено вірно, то нижня частина діалогового вікна стане активною (малюнок 5.23)

Малюнок 5.23
Нижня частина названа "Перелік робіт". Тут знаходиться список робіт, що проводяться з вагоном. Спочатку список порожній.
Для його заповнення потрібно на полі даних натиснути правою кнопкою миші і вибрати з меню, що "Додати". Відкриється діалогове вікно "Замовлення" (малюнок 5.24), де потрібно внести дані: Номер замовлення, Цех замовник, Цех виконавець і вибрати із запропонованого списку в нижній частині діалогового вікна вид послуги.

Малюнок 5.24
Поле Номер замовлення є числовим. Тому в разі введення літер або символів з'явиться повідомлення (малюнок 5.25):

Малюнок 5.25
У вікні необхідно натиснути "Оk" і виправити невірно введені дані.
Дані для заповнення полів Цех замовник, Цех виконавець беруться із списків (малюнок 5.26).

Малюнок 5.26
Для вибору цеху потрібно клацнути два рази лівою клавішею мишки на потрібному номері цеху. Для того щоб додати до списку цех потрібно ввести в поле Цех замовник / виконавець номер цеху і натиснути "Оk", після чого новий номер цеху з'явиться в списку. Для того щоб видалити зі списку номер цеху, необхідно клацнути правою кнопкою миші на потрібному номері цеху в поле даних і в меню вибрати "Видалити". Цех буде видалено.
Щоб вибрати необхідний вид послуги зі списку в нижній частині діалогового вікна, потрібно двічі клацнути лівою кнопкою миші по потрібній послугу. Після чого дані будуть додані. Послуги можна додавати, видаляти і редагувати.
Щоб додати послуги потрібно правою кнопкою миші натиснути на поле даних і в меню вибрати "Додати". Після чого з'явиться діалогове вікно "Довідник з цінами" (рисунок 5.27).

Малюнок 5.27
У цьому вікні можна додати послугу, внісши дані по ній: Вид роботи, Одиниця виміру, Ціна за одиницю виміру. Виходячи з цих даних, розраховується вартість послуги, наданої для конкретного вагона. Після введення даних потрібно натиснути кнопку "Оk". Після чого новий вид послуги з'явиться в списку.
Дані для заповнення поля Вид роботи беруться зі списку (малюнок 5.28).

Малюнок 5.28
Для вибору виду послуги потрібно клацнути два рази лівою клавішею мишки на потрібній послугу. Для того щоб додати до списку нову послугу потрібно ввести в полі Вид послуг назву послуги і натиснути "Оk", після чого нова послуга з'явиться в списку. Для того щоб видалити зі списку послугу, необхідно клацнути правою кнопкою миші на назві послуги в поле даних і в меню вибрати "Видалити". Послуга буде видалена.
Дані для заповнення поля Одиниця виміру беруться з списку (рисунок 5.29).

Малюнок 5.29
Для вибору одиниці вимірювання потрібно клацнути два рази лівою клавішею миші на потрібній одиниці виміру. Для того, щоб додати до списку нову одиницю вимірювання потрібно ввести в полі Одиниця виміру назва одиниці вимірювання та натиснути "Оk", після чого нова одиниця вимірювання з'явиться в списку. Для того, щоб видалити зі списку одиницю виміру, необхідно клацнути правою кнопкою миші на назві одиниці вимірювання в поле даних і в меню вибрати "Видалити". Одиниця виміру буде видалена.
Для редагування вже наявної послуги, необхідно правою кнопкою миші клацнути на потрібному рядку і в меню вибрати "Редагувати". Після чого з'являється вікно редагування (рисунок 5.30).

Малюнок 5.30
У цьому вікні можна змінити вид роботи, одиницю виміру і ціну за одиницю виміру описаним вище способом.
Для видалення будь-якої послуги зі списку необхідно правою кнопкою миші натиснути на потрібному рядку і в меню вибрати "Видалити".
Після введення всіх даних, в основному екрані з'являється новий рядок з доданою інформацією.
Також інформацію можна редагувати і видаляти. Для цього на потрібному рядку необхідно клацнути правою кнопкою миші і вибрати в меню, що "Редагувати" або "Видалити". При виборі "Редагувати" відкривається вікно редагування, де можна змінювати інформацію описаним вище способом. При виборі "Видалити" рядок видаляється зі списку.
Також в головній формі організований пошук. Для цього необхідно натиснути клавіші ctrl + f, після чого з'явиться вікно пошуку (рисунок 5.31).

Малюнок 5.31
Пошук здійснюється по інвентарному номеру вагону. Для пошуку необхідно в полі ввести інвентарний номер вагона і натиснути кнопку "Ok".

Глава 6. Вибір інструментальних засобів

6.1 Вибір апаратних засобів

При виборі апаратних засобів для розробки програмного продукту (ПП) найбільшу роль відіграє чинник швидкодії роботи ПЕОМ. Оскільки саме від нього залежить час розробки ПП, а відповідно витрати на розробку і його собівартості.
Вимоги, що пред'являються до операційної системи: операційна система Win 2K SP4 або WinXP до встановлених MDAC (Microsoft Data Access Components) 2.6 і раніше, а також Microsoft Jet 4.0.
Вимоги до апаратної частини комп'ютера визначаються встановленою операційною системою.

6.2 ERwin - сучасний засіб проектування баз даних

Проектування инфологической моделі бази даних здійснювалося за допомогою інструментів автоматизованого проектування та створення програм, які прийнято називати CASE-інструментами (Computer-Aided Software Engineering), а саме, ERwin компанії Computer Associates. Використання CASE-інструментів сприяє підвищенню продуктивності праці розробників і забезпечення ефективності самої системи, що розробляється.
ERwin 4.0 - потужний і просте у використанні засіб конструювання баз даних, завоювало широке визнання і популярність. Воно забезпечує високу продуктивність праці при розробці і супроводі додатків з використанням баз даних. ERwin дозволяє наочно відобразити структуру та основні елементи БД. Завдяки інтеграції з популярними середовищами розробки програм, ERwin дозволяє прискорити створення додатків для обробки даних.
ERwin полегшує проектування баз даних. Для цього досить створити графічну ER-модель (сутність-зв'язок), що задовольняє всім вимогам до даних і затвердити правила для створення логічної моделі, яка відображає всі елементи, атрибути, відносини і угруповання. Можна розширити можливості ERwin, скориставшись унікальною підтримкою користувацьких властивостей для введення в модель будь-якої додаткової інформації, значимої для діяльності підприємства.
ERwin - не просто інструмент для "малювання"; він автоматизує процес проектування. Наприклад, ERwin передбачає можливість створення каталогу найбільш часто використовуваних атрибутів, що забезпечує узгодженість імен і описів за всім проектом. Уявлення БД підтримуються як інтегровані компоненти моделі, що дозволяє автоматично відображати в їх описах зміни, внесені у базові таблиці. Автоматичне перенесення ключів забезпечує посилальну цілісність бази даних. Крім того, ERwin дозволяє працювати з великими моделями загальнокорпоративного масштабу, розбиваючи їх на фрагменти і легко керовані підмножини, надаючи окремим фахівцям можливість зосередити свої зусилля в певній галузі. Можливість збереження відображень дозволяє зберігати безліч уявлень однієї предметної області, орієнтованих на різну цільову аудиторію. Створені за допомогою ERwin моделі даних можна редагувати, переглядати і роздруковувати різними способами.
ERwin - не тільки кращий інструмент для проектування баз даних, а й засіб для їх швидкого створення. ERwin оптимізує модель відповідно з фізичними характеристиками цільової бази даних. На відміну від інших інструментальних засобів ERwin автоматично підтримує узгодженість логічної і фізичної схем і здійснює перетворення логічних конструкцій, таких як відносини "багато до багатьох", в їх реалізацію на фізичному рівні.
ERwin встановлює природну динамічну зв'язок між моделлю і базою даних, що дозволяє реалізувати як прямий, так і зворотний інжиніринг. Використовуючи цей зв'язок, ERwin автоматично генерує таблиці, уявлення, індекси, правила підтримки цілісності посилань (первинних і зовнішніх ключів), встановлює значення за замовчуванням і обмеження для доменів / стовпців.
ERwin інтегрує проектування бази даних в процес розробки програми. Завдяки можливостям взаємодії з популярними засобами розробки для архітектури клієнт / сервер і Web, ERwin підтримує відповідність між серверною базою даних і формами в клієнтській частині, дозволяючи прискорити створення високоякісних додатків.
CASE-засіб ERWin було обрано в якості засобу проектування бази даних з наступних причин:
ERWin підтримує пряме (створення БД на основі моделі) і зворотне (генерація моделі за наявною базі даних) проектування для 20 типів СУБД;
збільшує продуктивність праці завдяки зручному інтерфейсу і зменшує число рутинних операцій, полегшує і скорочує роботу;
дозволяє максимально підвищити продуктивність інформаційної системи завдяки підтримці роботи з БД на фізичному рівні, враховуючи особливості кожної конкретної СУБД;
підтримує методологію структурного моделювання;
дозволяє повторно використовувати компоненти створених раніше моделей, а також використовувати напрацювання інших розробників, що підвищує ефективність роботи;
дозволяє переносити структуру БД з СУБД одного типу СУБД в іншій;
дозволяє документувати структуру БД (дозволить отримати звіти презентаційної якості);
продукт можна використовувати на всіх стадіях життєвого циклу баз даних: при проектуванні, розробці, тестуванні та підтримки;
дозволяє отримати точну і наочну інформацію, де зберігаються дані і як отримати до них доступ;
дозволяє, використовуючи візуальні засоби, описати структуру БД, а потім автоматично згенерувати файли даних для будь-якого типу СУБД;
продукт легко освоїти. [11]

6.3 Microsoft Access 2003

Microsoft Access 2003 є потужну і стійку 32-розрядну систему управління реляційними базами даних (СУРБД), яка призначена для створення настільних додатків і додатків клієнт / сервер, що працюють під управлінням Windows 2000 і XP, а також.
Microsoft Access з дня своєї появи в 1992р. залишається одним з найбільш гнучких і ефективних додатків Office. Про це свідчить розвинений набір засобів, достоїнства яких визнаються навіть самими досвідченими користувачами баз даних, а простота використання, притаманна всім програмам Office, робить ці кошти доступними і для початківців користувачів. У додатку Access 2003 відмічені якості отримали подальший розвиток, надавши в розпорядження розробникам і досвідченим користувачам нові функціональні можливості, що дозволяють здійснювати доступ до важливих даних і проводити їх глибокий аналіз, а також створювати ефективні нові рішення в цій області. У той же час Access спрощує для початківців користувачів знайомство з можливостями цього додатка.
Продуктивність і ефективність.
Чи застосовується база даних для фіксації відомостей про продажі в межах компанії або просто для ведення будь-яких списків для особистого користування, робота з нею часто далеко не так проста і інтуїтивно зрозуміла, як хотілося б. Основна мета при розробці Access 2003 полягала в спрощення побудови та застосування баз даних. Ця мета була досягнута завдяки наданню користувачам широкого кола засобів, що дозволяють легко відшукувати та застосовувати більшу частину можливостей продукту.
Доступ до інформації та її аналіз.
Другий з основних цілей розробки Access 2003 було спрощення доступу до важливої ​​інформації та її аналізу, незалежно від місця розташування відповідних даних. У додатку Access 2003 розширені можливості користувача по доступу до інформації баз даних корпоративного рівня, наприклад Microsoft SQL Server. Крім того, в цій версії програми Access удосконалено способи аналізу користувачами цих даних за допомогою динамічних зведених таблиць і зведених діаграм, раніше були тільки в додатку Excel, а також у вигляді сторінок доступу до даних, що дозволяють користувачам передавати програми корпоративних баз даних в Internet.
Розширені можливості програмування для розробників.
Третя основна мета творців Access полягала у наданні розробникам коштів, необхідних для створення розвинутих складних баз даних, легко інтегруються зі структурою даних підприємства, забезпечуючи при цьому пряму і зворотну сумісність з існуючими та новими рішеннями. Access 2003 надає засоби для створення рішень, що інтегрують і використовують переваги Internet-стандартів, таких як XML, XSL і динамічні веб-сторінки. Ці рішення дозволяють краще враховувати можливості спільного використання та представлення даних в інтрамережі і Internet.
Підтримка декількох мов.
Остання з цілей, поставлених при розробці Access 2003, полягала у наданні транснаціональним корпораціям і організаціям, в яких користувачі говорять на різних мовах, зручних способів роботи з додатком. Ця мета була досягнута завдяки вдосконаленням, що дозволяє працювати з різномовними текстами в базах даних, а також відображати і обробляти їх.
У Access повною мірою реалізовано управління реляційними базами даних:
· Система підтримує первинні та зовнішні ключі;
· Забезпечує цілісність даних на рівні ядра, що запобігає несумісні операції оновлення або видалення даних;
· Таблиці в Access забезпечені засобами перевірки допустимості даних, що запобігають некоректний введення;
· Підтримує всі необхідні типи полів;
· Система забезпечує повну підтримку порожніх значень;
· Система Access підтримує обробку транзакцій з гарантією їх цілісності;
· Передбачений захист на рівні користувача, що дозволяє контролювати доступ до даних окремих користувачів і цілих груп;
· Передбачена контекстно-залежна довідка;
· Дозволяє імпортувати і експортувати файли багатьох відомих форматів. [12]
У дипломній роботі була використана також одна з найбільш потужних можливостей Access, що одночасно є і найбільш важливою - створення запитів. Після подібного зв'язування таблиці виступають вже як одне ціле, і тепер можна будувати запити стосовно будь-якими даними в них. Можна вибирати конкретні поля, визначати порядок сортування, створювати обчислювані вирази і вводити критерії відбору потрібних записів. Створені таким чином запити стали основою для проектування призначеного для користувача інтерфейсу.